Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

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


+
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
Copy link to this message
-
Re: making a hadoop-common test run if a property is set
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.
+
Steve Loughran 2012-12-18, 16:42
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB