You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Shane Witbeck <sh...@digitalsanctum.com> on 2008/11/18 17:04:29 UTC
differing behavior of running integration tests
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?
-Shane
Re: differing behavior of running integration tests
Posted by Shane Witbeck <sh...@digitalsanctum.com>.
Is there a public project that illustrates this in more detail?
-Shane
On Tue, Nov 18, 2008 at 12:16 PM, Assaf Arkin <ar...@intalio.com> wrote:
> On Tue, Nov 18, 2008 at 8:46 AM, Shane Witbeck <sh...@digitalsanctum.com>
> wrote:
> > 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.
>
> The way we use it right now, you would have a structure like this:
>
> app
> comp1
> comp2
> tests
>
> We have two components in two sub-projects. Each sub-project includes
> the unit tests for that specific component, so all the unit tests for
> comp1 would go in the app:comp1 project.
>
> Separately, we assemble an application from these components, the
> integration tests for the application are placed in the tests
> sub-project (they don't belong in either comp1 or comp2).
>
> Assaf
>
> >
> > -Shane
> >
> >
> > On Tue, Nov 18, 2008 at 11:21 AM, Assaf Arkin <ar...@intalio.com> wrote:
> >
> >> On Tue, Nov 18, 2008 at 8:04 AM, Shane Witbeck <
> shane@digitalsanctum.com>
> >> 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
> >> >
> >>
> >
>
Re: differing behavior of running integration tests
Posted by Assaf Arkin <ar...@intalio.com>.
On Tue, Nov 18, 2008 at 8:46 AM, Shane Witbeck <sh...@digitalsanctum.com> wrote:
> 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.
The way we use it right now, you would have a structure like this:
app
comp1
comp2
tests
We have two components in two sub-projects. Each sub-project includes
the unit tests for that specific component, so all the unit tests for
comp1 would go in the app:comp1 project.
Separately, we assemble an application from these components, the
integration tests for the application are placed in the tests
sub-project (they don't belong in either comp1 or comp2).
Assaf
>
> -Shane
>
>
> On Tue, Nov 18, 2008 at 11:21 AM, Assaf Arkin <ar...@intalio.com> wrote:
>
>> On Tue, Nov 18, 2008 at 8:04 AM, Shane Witbeck <sh...@digitalsanctum.com>
>> 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
>> >
>>
>
Re: differing behavior of running integration tests
Posted by Shane Witbeck <sh...@digitalsanctum.com>.
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 <ar...@intalio.com> wrote:
> On Tue, Nov 18, 2008 at 8:04 AM, Shane Witbeck <sh...@digitalsanctum.com>
> 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
> >
>
Re: differing behavior of running integration tests
Posted by Assaf Arkin <ar...@intalio.com>.
On Tue, Nov 18, 2008 at 8:04 AM, Shane Witbeck <sh...@digitalsanctum.com> 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
>