On 18 December 2012 09:11, Colin McCabe <cmcc...@alumni.cmu.edu> wrote:
> On Tue, Dec 18, 2012 at 1:05 AM, Colin McCabe <cmcc...@alumni.cmu.edu> > 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.
