Thanks for the explanation. It seems the behavior is as designed. In the case where top level and sub projects have integration tests what's the best way to have a finer grained control over which tests get executed when?
For example, I'd like to be able to mark certain tests in a project (top-level or sub project) either unit or integration. It seems you're stuck marking all tests for a specific project as being integration tests and they only get executed if you run a test or package command from the top-level project. -Shane On Tue, Nov 18, 2008 at 11:21 AM, Assaf Arkin <[EMAIL PROTECTED]> wrote: > On Tue, Nov 18, 2008 at 8:04 AM, Shane Witbeck <[EMAIL PROTECTED]> > wrote: > > I'm having an issue which I'm not sure is an issue. I have a project > > structure where some subprojects are marked with 'test using > :integration'. > > If I run 'buildr clean package' from a subproject the tests won't > execute. > > However, if I run 'buildr clean package' from the parent project, the > tests > > will execute. > > > > Is this the correct behavior? > > In a sense, integration tests belong to the top-level projects: they > test all the components built and packaged as part of that project. > When you package the top-level projects, it follows by running > integration tests. > > That doesn't make as much sense for a sub-project: the integration > tests are written there for modularity, but they don't necessarily > test that sub-project. You can still run buildr integration there to > just run this set of integration tests. > > Assaf > > > > > > -Shane > > >
