Test assumptions

Hi Kent,

It’s been a while, but IIRCC, that code was an attempt to early detect issues caused by differences between the command line build and IDE builds (like the current directory when running tests, output dir, etc). A number of tests require resources to be in specific relative locations. If you search for tests that call this utility method, that will give you a good idea of which tests make such assumptions. If you find some other way to reliably find the needed resources, then it makes sense to replace existing approaches with the “new way”, but that may involve propagating the “new way” to bunch of tests.

As a stop gap, measure, providing a list of “common” directories sounds like a good option (and avoids the need to comb through a bunch of tests right away). Basically, the check is there to try and save people time when tests will fail due to IDE differences - and there were a bunch of folks hitting this issue in the past. IIRCC the thinking was this helper method would quickly detect the problem, and make it clear so the IDE could be setup to match the command line. Not sure if Eclipse can handle that well, as it is the one IDE I know of that freaks out if something else builds output (like the command line) into the same directory as the IDE. (I’m an IntelliJ user, so command line and IDE building to the same output dir works great). Maybe checking for some already know ‘resource’ file would be enough (thus no need for a new ‘token’ file)?

Dan


Message: 5
Date: Wed, 15 Jan 2014 16:43:23 -0600 (CST)
From: "Kent R. Spillner" <[email protected]>
Subject: Re: [Cruisecontrol-devel] Test assumptions
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain;charset=UTF-8

Another issue: CruiseControlControllerTest calls TestUtil.getTargetDir(), which explicitly checks that the test is running out of a directory named "target."

That works with our current Ant build scripts, but it's pretty fragile.  I only noticed it because my IDE's default output directory isn't named target.  Looking at the commit message that introduced this check, however, it sounds like there was a good reason for doing this.

Dan - do you remember working on that?  Do you think all of those asserts are still necessary, or is it safe to drop them?  Did you actually encounter issues that would have been caught by those asserts, or were you just being extra careful?  If it's still necessary what do you think about relaxing the check to include a list of common directory names?  Or what about checking for the presence of some token in the root of the classpath directory, such as an empty this_properties_file_must_exist_for_all_tests.properties?

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

_______________________________________________
Cruisecontrol-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cruisecontrol-devel