Mailing-List: contact buildr-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: buildr-user@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <153af7a10811180950x38a7dff5ud36628ea9a6f747d@mail.gmail.com>
Date: Tue, 18 Nov 2008 12:50:53 -0500
From: "Shane Witbeck" <shane@digitalsanctum.com>
To: buildr-user@incubator.apache.org
Subject: Re: differing behavior of running integration tests
In-Reply-To: <3de5d7d20811180916t491f7baesa07ed4923389494c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_41870_24229561.1227030653932"
References: <153af7a10811180804p6f9216a5scfa75b66cc0919a8@mail.gmail.com>
	 <3de5d7d20811180821o74c2597dp8a42a38afd872394@mail.gmail.com>
	 <153af7a10811180846o5ba34be1ofbac8e676566d4cc@mail.gmail.com>
	 <3de5d7d20811180916t491f7baesa07ed4923389494c@mail.gmail.com>

------=_Part_41870_24229561.1227030653932
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Is there a public project that illustrates this in more detail?

-Shane


On Tue, Nov 18, 2008 at 12:16 PM, Assaf Arkin <arkin@intalio.com> wrote:

> On Tue, Nov 18, 2008 at 8:46 AM, Shane Witbeck <shane@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 <arkin@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
> >> >
> >>
> >
>

------=_Part_41870_24229561.1227030653932--