Great thread, this is really helpful stuff!
> Though, pedantically speaking, I wouldn't classify any of those as unit
> tests. Even though the 'test' tasks _can_ be used to run all kinds of
> tests, I think that's not really what they're for.
The tests I'm working on are definitely not what I'd think of as
"unit" tests. They are not low-level, they are slow, they use the file
system and other systems (written in other programming languages) that
must be independently installed and configured (db server, reporting
engine). I would probably have them run on a ci server on every commit
or nightly, given the possibility of external dependencies changing.
Sounds like I'm not using the task for its intended purpose.
> I think unit tests by definition should be deterministic... and
> should only run when code/configuration changes.
Agreed. Well put. In this case I may have just been surprised by a
build system/convention that makes sense and is fun to use. :)
Maybe I'll make a "source set" for an integration test suite. Anyone
have any examples of exemplary code doing this? (I'm happy to start a
new thread about same if that's better list etiquette)
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email