Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # dev - making a hadoop-common test run if a property is set

Copy link to this message
Re: making a hadoop-common test run if a property is set
Steve Loughran 2012-12-18, 10:25
On 18 December 2012 09:11, Colin McCabe <[EMAIL PROTECTED]> wrote:

> On Tue, Dec 18, 2012 at 1:05 AM, Colin McCabe <[EMAIL PROTECTED]>
> wrote:
> >
> >> 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.
> best,
> Colin
> 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.