Steve Loughran 2012-12-14, 17:56
Colin McCabe 2012-12-14, 18:57
Steve Loughran 2012-12-17, 10:06
Tom White 2012-12-17, 16:06
Steve Loughran 2012-12-17, 19:03
Colin McCabe 2012-12-18, 09:05
Steve Loughran 2012-12-18, 10:32
Colin McCabe 2012-12-18, 09:11
On 18 December 2012 09:11, Colin McCabe <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 18, 2012 at 1:05 AM, Colin McCabe <[EMAIL PROTECTED]>
> >> another tactic could be to have specific test projects: test-s3,
> >> test-openstack, test-... which contain nothing but test cases. You'd set
> >> jenkins up those test projects too -the reason for having the separate
> >> names is to make it blatantly clear which tests you've not run
> > I dunno. Every time a project puts unit or system tests into a
> > separate project, the developers never run them. I've seen it happen
> > enough times that I think I can call it an anti-pattern by now. I
> > like having tests alongside the code-- to the maximum extent that is
> > possible.
> Just to be clear, I'm not referring to any Hadoop-related project
> here, just certain other open source (and not) ones I've worked on.
> System/unit tests belong with the rest of the code, otherwise they get
> stale real fast.
> It sometimes makes sense for integration tests to live in a separate
> repo, since by their nature they're usually talking to stuff that
> lives in multiple repos.
> Oh, I understood that. Even with jenkins set up to build a chain of
projects, there's a risk (in my experience at a former employer ) that the
people upstream wouldn't correlate mail from jenkins "project D test
failing" with their action to commit something.
Even so, there's always conflict between short-run unit tests and full
tests on a cluster of size >1. a short test cycle boosts desktop dev, but
you still want to be thorough.
Steve Loughran 2012-12-18, 16:42