I found the same thing (or at least the alternate wasn't obvious) when I recently set up the same functionality.
I got around it with a bit of a hack. I have a "longtests" environment in profile.yaml, and unless I'm in that environment, I exclude any test file named *LongTest. This, of course, means that developers have to know which is which. But it does allow me to have a mode where I do DBUnit setup/teardown, Spring config loading, and so on and so forth. (The build machine runs them at every check-in, but I assume developers will get frustrated if they have to run the time-consuming tests all the time.) Derrick On Tue, Sep 28, 2010 at 7:15 PM, Antoine Toulme <[email protected]>wrote: > I think that's the case right now, indeed. Buildr was trying to be more > granular and say, we're either building java, or building a big war. The > big > assembly project at the end is the one that should require integration > tests. > > At least I think that was the idea. > > On Tue, Sep 28, 2010 at 18:16, Peter Donald <[email protected]> > wrote: > > > Hi, > > > > I am in the process of converting a bunch of builds based on > > ant/maven/rake to buildr. One of the patterns that I can not see how > > to directly translate into buildr is the single project with multiple > > test types within it. i.e. A project has integration and unit tests > > both written in java and both stored in test hierarchy. It also has > > ruby based integration tests sitting side by side the java test code. > > AFAICS buildr is not really set up for this scenario. It seems that > > for each project there can only be one test invocation, one test > > framework and can not run parts at both integration testing time and > > unit testing time. Is this correct? > > > > Any suggestions on how to deal with this? > > > > -- > > Cheers, > > > > Peter Donald > > > -- Writer. Programmer. Puzzle Designer. http://www.obsessionwithfood.com
