Hi, On Wed, Sep 29, 2010 at 12:24 PM, Derrick Schneider <[email protected]> wrote: > 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.)
Right this is the approach that I ended up using. Tests that run against a DB / Message Broker / etc are guarded against (with an environment setting in my case that is set on the CI). On Wed, Sep 29, 2010 at 1:20 PM, Rhett Sutphin <[email protected]> wrote: > Yes. Each buildr project can only have one test type (either integration or > unit) and one test framework (junit, rspec, etc.). I guess I see the first as a limitation of buildr and the other as a rasonable assumption ;-) >> Any suggestions on how to deal with this? > > I use a separate subproject for integration tests -- i.e., a subproject that > only has tests in it and which depends on whatever module(s) I'm trying to > integratedly test. It might even be possible to have a subproject definition > which, through the :base_dir option, executed tests which are physically > alongside the unit tests in the parent project. I haven't tried that, though. Certainly an option but I can imagine that almost every bundle that we write should have both unit and integration tests and it does not seem entirely reasonable to double the number of projects to accomodate this. Dooable - especially as we already wrap the define() method and customize the project definition anyhoo but a bit ugly. On Wed, Sep 29, 2010 at 3:21 PM, Alex Boisvert <[email protected]> wrote: > type1 = TestTask.define_task('test-type1') > type1.include [...] > > type2 = TestTask.define_task('test-type2') > type2.include [...] > > ... > > test.enhance [type1, type2] > > However as it stands, the code makes several assumptions that there's only > one TestTask per project. It's certainly doable but may require > non-trivial changes to the code. I have a stop gap measure in place but I guess what I would like to see when/if I get a chance is something like test.include 'org.example.SimpleTestCase' integration.test.include 'org.example.MyLongRunningDbTest' Something I may look at down the track. -- Cheers, Peter Donald
