Re: Test strategy

[Prasad Kashyap <go...@gmail.com>]

I have completed items 1 and 3 of the test strategy outlined above.
With that we now have the geronimo-deployment-plugin in maven 2.

I have now begun working on item 2 which is to create a separate
itests sub-project that will act as a catchment of the itests from the
various modules. Now this is what we should look into - have the
itests subproject as a dependency of the Geronimo project, and include
the tests during the integration-phase of the lifecycle in G's build.
Yet keep it separate, and thus be able to run the itests against any
G's distribution binary separately. This would be the best of both
worlds. I'll investigate the possibility of doing so.

Jason, it is at this point that I have begun looking at TestNG. I have
some questions for you.
- Have you used it yourself ?
- How do you think it will fit into the picture I painted above where
the testsuites will be contributed by folks from the the various
modules ?
- Do they all have to use TestNG then ?

We need a framework that can perform system level tests 'coz that is
what itests are at this point.

Cheers
Prasad

On 1/31/06, Jason Dillon <ja...@planet57.com> wrote:
> Anyone thought about using TestNG?
>
> Its xml suite def and grouping support would be nice to define these itest suites.
>
> --jason
>
>
> -----Original Message-----
> From: David Blevins <da...@visi.com>
> Date: Mon, 30 Jan 2006 20:41:39
> To:dev@geronimo.apache.org
> Subject: Re: Test strategy
>
>
> On Jan 30, 2006, at 7:43 PM, Prasad Kashyap wrote:
> > I would like to solicit the views of others too like you and get their
> > views and opinions.
>
> Great.  I poked some other people in irc to get involved as well.
> Here is hoping.... :)  More input is going to make for a better
> community supported solution.
>
> >>> - The tests can all be run or only a subset of suites can be run
> >>> quite easily.
> >
> >> When you say "easily" do you mean by virtue of them being separate or
> >> some other idea?
> >
> > When I said we could run a subset of tests "easily" when the itests
> > are run "on" assemblies, I meant that it would be relatively easier to
> > selectively include/exclude tests (by categories) than when compared
> > to doing the same if the itests are embedded with their modules.
>
> I think I follow what you mean.  I guess the haze is in what you mean
> by "embedded."
>
> As I'm not sure, I will just state in more specific terms that I have
> never argued for putting the actual testing source code inside any
> particular assembly module -- this code is big, bulky, has a lot of
> deps itself and some pretty specific packaging needs.  I have argued
> for simply running the    big test suite during the lifecycle of an
> assembly.
>
> Not sure if that is coming across well, or if it's being assumed that
> since I've recommended running the integration tests on an assembly,
> during the integration test phase of it's lifecycle, that the test
> source of course must be in the assembly as well.  I believe we agree
> on keeping the test source in modules separate and organized.
>
> >>> - The tests will be grouped logically into suites or categories.
> >>> Each
> >>> individual test will fall in one of these suites.
> >
> >> Not sure of your usage of the word "test" in this sentence.  In junit
> >> terms is that TestSuite, TestCase, or individual test method.  Can
> >> you clarify?
> >
> > I meant TestCase. For. eg, we could have a TestSuite called, "System"
> > which will have test cases from many different modules. We could say
> > that these form the core set of tests. If the System suite passed, we
> > have somewhat of a stable binary with the caveat that all functions
> > may not work.
>
> That is much clearer to me, thanks.  I do like the sort of parent
> module name you came up with of "System" too -- it's a keeper.
>
> At this point, I will note that it is possible put a single
> SuperServerSystemTest.java TestSuite in the SuperServer assemblies
> module (for example) that adds only the tests from the many different
> test modules that apply to that assembly.
>
> > In summary, the cons of running the itests "on" assemblies is that it
> > goes against the m2 lifecycle. And even though integration-test is an
> > m2 lifecycle phase, we are not exploiting it's usage but calling it
> > explicity again. The same has to be done for the deploy phase too.
>
> You captured that quite well.
>
> It occurred to me while writing a sentence above that there is no
> clear distinction between "on" and "during".  In all cases you are
> quite literally running the tests on the assembly.  The better
> distinction is whether or not you wish to run them "during" it's
> lifecycle or "after" in the lifecycle of a separate module.
>
> -David
>

Re: Test strategy

[Prasad Kashyap <go...@gmail.com>]

Here's another thing we should look into considering sooner or later;
the maven-cargo-plugin. (http://cargo.codehaus.org).

It provides goals to start/stop various containers and deploy/undeploy
J2EE artifacts into those containers.

For now, it doesn't have a goal for Jetty 5.x container which we need
and it's Tomcat 5.5.x goal needs JDK 1.5 which don't have support yet.

But once we have these things squared away, this is something worth
considering for use in our itests.

Cheers
Prasad

On 2/9/06, Prasad Kashyap <go...@gmail.com> wrote:
> Oops.. sorry. This should have helped.
>
> http://www.mail-archive.com/dev@geronimo.apache.org/msg16726.html
>
> Cheers
> Prasad
>
> On 2/9/06, David Blevins <da...@visi.com> wrote:
> > On Feb 9, 2006, at 9:10 AM, Prasad Kashyap wrote:
> >
> > > I have completed items 1 and 3 of the test strategy outlined above.
> > > With that we now have the geronimo-deployment-plugin in maven 2.
> >
> > What are items 1 and 3?  Don't see an outline.
> >
> > -David
> >
> >
> > > I have now begun working on item 2 which is to create a separate
> > > itests sub-project that will act as a catchment of the itests from the
> > > various modules. Now this is what we should look into - have the
> > > itests subproject as a dependency of the Geronimo project, and include
> > > the tests during the integration-phase of the lifecycle in G's build.
> > > Yet keep it separate, and thus be able to run the itests against any
> > > G's distribution binary separately. This would be the best of both
> > > worlds. I'll investigate the possibility of doing so.
> > >
> > > Jason, it is at this point that I have begun looking at TestNG. I have
> > > some questions for you.
> > > - Have you used it yourself ?
> > > - How do you think it will fit into the picture I painted above where
> > > the testsuites will be contributed by folks from the the various
> > > modules ?
> > > - Do they all have to use TestNG then ?
> > >
> > > We need a framework that can perform system level tests 'coz that is
> > > what itests are at this point.
> > >
> > > Cheers
> > > Prasad
> > >
> > > On 1/31/06, Jason Dillon <ja...@planet57.com> wrote:
> > >> Anyone thought about using TestNG?
> > >>
> > >> Its xml suite def and grouping support would be nice to define
> > >> these itest suites.
> > >>
> > >> --jason
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: David Blevins <da...@visi.com>
> > >> Date: Mon, 30 Jan 2006 20:41:39
> > >> To:dev@geronimo.apache.org
> > >> Subject: Re: Test strategy
> > >>
> > >>
> > >> On Jan 30, 2006, at 7:43 PM, Prasad Kashyap wrote:
> > >>> I would like to solicit the views of others too like you and get
> > >>> their
> > >>> views and opinions.
> > >>
> > >> Great.  I poked some other people in irc to get involved as well.
> > >> Here is hoping.... :)  More input is going to make for a better
> > >> community supported solution.
> > >>
> > >>>>> - The tests can all be run or only a subset of suites can be run
> > >>>>> quite easily.
> > >>>
> > >>>> When you say "easily" do you mean by virtue of them being
> > >>>> separate or
> > >>>> some other idea?
> > >>>
> > >>> When I said we could run a subset of tests "easily" when the itests
> > >>> are run "on" assemblies, I meant that it would be relatively
> > >>> easier to
> > >>> selectively include/exclude tests (by categories) than when compared
> > >>> to doing the same if the itests are embedded with their modules.
> > >>
> > >> I think I follow what you mean.  I guess the haze is in what you mean
> > >> by "embedded."
> > >>
> > >> As I'm not sure, I will just state in more specific terms that I have
> > >> never argued for putting the actual testing source code inside any
> > >> particular assembly module -- this code is big, bulky, has a lot of
> > >> deps itself and some pretty specific packaging needs.  I have argued
> > >> for simply running the    big test suite during the lifecycle of an
> > >> assembly.
> > >>
> > >> Not sure if that is coming across well, or if it's being assumed that
> > >> since I've recommended running the integration tests on an assembly,
> > >> during the integration test phase of it's lifecycle, that the test
> > >> source of course must be in the assembly as well.  I believe we agree
> > >> on keeping the test source in modules separate and organized.
> > >>
> > >>>>> - The tests will be grouped logically into suites or categories.
> > >>>>> Each
> > >>>>> individual test will fall in one of these suites.
> > >>>
> > >>>> Not sure of your usage of the word "test" in this sentence.  In
> > >>>> junit
> > >>>> terms is that TestSuite, TestCase, or individual test method.  Can
> > >>>> you clarify?
> > >>>
> > >>> I meant TestCase. For. eg, we could have a TestSuite called,
> > >>> "System"
> > >>> which will have test cases from many different modules. We could say
> > >>> that these form the core set of tests. If the System suite
> > >>> passed, we
> > >>> have somewhat of a stable binary with the caveat that all functions
> > >>> may not work.
> > >>
> > >> That is much clearer to me, thanks.  I do like the sort of parent
> > >> module name you came up with of "System" too -- it's a keeper.
> > >>
> > >> At this point, I will note that it is possible put a single
> > >> SuperServerSystemTest.java TestSuite in the SuperServer assemblies
> > >> module (for example) that adds only the tests from the many different
> > >> test modules that apply to that assembly.
> > >>
> > >>> In summary, the cons of running the itests "on" assemblies is
> > >>> that it
> > >>> goes against the m2 lifecycle. And even though integration-test
> > >>> is an
> > >>> m2 lifecycle phase, we are not exploiting it's usage but calling it
> > >>> explicity again. The same has to be done for the deploy phase too.
> > >>
> > >> You captured that quite well.
> > >>
> > >> It occurred to me while writing a sentence above that there is no
> > >> clear distinction between "on" and "during".  In all cases you are
> > >> quite literally running the tests on the assembly.  The better
> > >> distinction is whether or not you wish to run them "during" it's
> > >> lifecycle or "after" in the lifecycle of a separate module.
> > >>
> > >> -David
> > >>
> > >
> >
> >
>

Re: Test strategy

[Prasad Kashyap <go...@gmail.com>]

Oops.. sorry. This should have helped.

http://www.mail-archive.com/dev@geronimo.apache.org/msg16726.html

Cheers
Prasad

On 2/9/06, David Blevins <da...@visi.com> wrote:
> On Feb 9, 2006, at 9:10 AM, Prasad Kashyap wrote:
>
> > I have completed items 1 and 3 of the test strategy outlined above.
> > With that we now have the geronimo-deployment-plugin in maven 2.
>
> What are items 1 and 3?  Don't see an outline.
>
> -David
>
>
> > I have now begun working on item 2 which is to create a separate
> > itests sub-project that will act as a catchment of the itests from the
> > various modules. Now this is what we should look into - have the
> > itests subproject as a dependency of the Geronimo project, and include
> > the tests during the integration-phase of the lifecycle in G's build.
> > Yet keep it separate, and thus be able to run the itests against any
> > G's distribution binary separately. This would be the best of both
> > worlds. I'll investigate the possibility of doing so.
> >
> > Jason, it is at this point that I have begun looking at TestNG. I have
> > some questions for you.
> > - Have you used it yourself ?
> > - How do you think it will fit into the picture I painted above where
> > the testsuites will be contributed by folks from the the various
> > modules ?
> > - Do they all have to use TestNG then ?
> >
> > We need a framework that can perform system level tests 'coz that is
> > what itests are at this point.
> >
> > Cheers
> > Prasad
> >
> > On 1/31/06, Jason Dillon <ja...@planet57.com> wrote:
> >> Anyone thought about using TestNG?
> >>
> >> Its xml suite def and grouping support would be nice to define
> >> these itest suites.
> >>
> >> --jason
> >>
> >>
> >> -----Original Message-----
> >> From: David Blevins <da...@visi.com>
> >> Date: Mon, 30 Jan 2006 20:41:39
> >> To:dev@geronimo.apache.org
> >> Subject: Re: Test strategy
> >>
> >>
> >> On Jan 30, 2006, at 7:43 PM, Prasad Kashyap wrote:
> >>> I would like to solicit the views of others too like you and get
> >>> their
> >>> views and opinions.
> >>
> >> Great.  I poked some other people in irc to get involved as well.
> >> Here is hoping.... :)  More input is going to make for a better
> >> community supported solution.
> >>
> >>>>> - The tests can all be run or only a subset of suites can be run
> >>>>> quite easily.
> >>>
> >>>> When you say "easily" do you mean by virtue of them being
> >>>> separate or
> >>>> some other idea?
> >>>
> >>> When I said we could run a subset of tests "easily" when the itests
> >>> are run "on" assemblies, I meant that it would be relatively
> >>> easier to
> >>> selectively include/exclude tests (by categories) than when compared
> >>> to doing the same if the itests are embedded with their modules.
> >>
> >> I think I follow what you mean.  I guess the haze is in what you mean
> >> by "embedded."
> >>
> >> As I'm not sure, I will just state in more specific terms that I have
> >> never argued for putting the actual testing source code inside any
> >> particular assembly module -- this code is big, bulky, has a lot of
> >> deps itself and some pretty specific packaging needs.  I have argued
> >> for simply running the    big test suite during the lifecycle of an
> >> assembly.
> >>
> >> Not sure if that is coming across well, or if it's being assumed that
> >> since I've recommended running the integration tests on an assembly,
> >> during the integration test phase of it's lifecycle, that the test
> >> source of course must be in the assembly as well.  I believe we agree
> >> on keeping the test source in modules separate and organized.
> >>
> >>>>> - The tests will be grouped logically into suites or categories.
> >>>>> Each
> >>>>> individual test will fall in one of these suites.
> >>>
> >>>> Not sure of your usage of the word "test" in this sentence.  In
> >>>> junit
> >>>> terms is that TestSuite, TestCase, or individual test method.  Can
> >>>> you clarify?
> >>>
> >>> I meant TestCase. For. eg, we could have a TestSuite called,
> >>> "System"
> >>> which will have test cases from many different modules. We could say
> >>> that these form the core set of tests. If the System suite
> >>> passed, we
> >>> have somewhat of a stable binary with the caveat that all functions
> >>> may not work.
> >>
> >> That is much clearer to me, thanks.  I do like the sort of parent
> >> module name you came up with of "System" too -- it's a keeper.
> >>
> >> At this point, I will note that it is possible put a single
> >> SuperServerSystemTest.java TestSuite in the SuperServer assemblies
> >> module (for example) that adds only the tests from the many different
> >> test modules that apply to that assembly.
> >>
> >>> In summary, the cons of running the itests "on" assemblies is
> >>> that it
> >>> goes against the m2 lifecycle. And even though integration-test
> >>> is an
> >>> m2 lifecycle phase, we are not exploiting it's usage but calling it
> >>> explicity again. The same has to be done for the deploy phase too.
> >>
> >> You captured that quite well.
> >>
> >> It occurred to me while writing a sentence above that there is no
> >> clear distinction between "on" and "during".  In all cases you are
> >> quite literally running the tests on the assembly.  The better
> >> distinction is whether or not you wish to run them "during" it's
> >> lifecycle or "after" in the lifecycle of a separate module.
> >>
> >> -David
> >>
> >
>
>

Re: Test strategy

[David Blevins <da...@visi.com>]

On Feb 9, 2006, at 9:10 AM, Prasad Kashyap wrote:

> I have completed items 1 and 3 of the test strategy outlined above.
> With that we now have the geronimo-deployment-plugin in maven 2.

What are items 1 and 3?  Don't see an outline.

-David


> I have now begun working on item 2 which is to create a separate
> itests sub-project that will act as a catchment of the itests from the
> various modules. Now this is what we should look into - have the
> itests subproject as a dependency of the Geronimo project, and include
> the tests during the integration-phase of the lifecycle in G's build.
> Yet keep it separate, and thus be able to run the itests against any
> G's distribution binary separately. This would be the best of both
> worlds. I'll investigate the possibility of doing so.
>
> Jason, it is at this point that I have begun looking at TestNG. I have
> some questions for you.
> - Have you used it yourself ?
> - How do you think it will fit into the picture I painted above where
> the testsuites will be contributed by folks from the the various
> modules ?
> - Do they all have to use TestNG then ?
>
> We need a framework that can perform system level tests 'coz that is
> what itests are at this point.
>
> Cheers
> Prasad
>
> On 1/31/06, Jason Dillon <ja...@planet57.com> wrote:
>> Anyone thought about using TestNG?
>>
>> Its xml suite def and grouping support would be nice to define  
>> these itest suites.
>>
>> --jason
>>
>>
>> -----Original Message-----
>> From: David Blevins <da...@visi.com>
>> Date: Mon, 30 Jan 2006 20:41:39
>> To:dev@geronimo.apache.org
>> Subject: Re: Test strategy
>>
>>
>> On Jan 30, 2006, at 7:43 PM, Prasad Kashyap wrote:
>>> I would like to solicit the views of others too like you and get  
>>> their
>>> views and opinions.
>>
>> Great.  I poked some other people in irc to get involved as well.
>> Here is hoping.... :)  More input is going to make for a better
>> community supported solution.
>>
>>>>> - The tests can all be run or only a subset of suites can be run
>>>>> quite easily.
>>>
>>>> When you say "easily" do you mean by virtue of them being  
>>>> separate or
>>>> some other idea?
>>>
>>> When I said we could run a subset of tests "easily" when the itests
>>> are run "on" assemblies, I meant that it would be relatively  
>>> easier to
>>> selectively include/exclude tests (by categories) than when compared
>>> to doing the same if the itests are embedded with their modules.
>>
>> I think I follow what you mean.  I guess the haze is in what you mean
>> by "embedded."
>>
>> As I'm not sure, I will just state in more specific terms that I have
>> never argued for putting the actual testing source code inside any
>> particular assembly module -- this code is big, bulky, has a lot of
>> deps itself and some pretty specific packaging needs.  I have argued
>> for simply running the    big test suite during the lifecycle of an
>> assembly.
>>
>> Not sure if that is coming across well, or if it's being assumed that
>> since I've recommended running the integration tests on an assembly,
>> during the integration test phase of it's lifecycle, that the test
>> source of course must be in the assembly as well.  I believe we agree
>> on keeping the test source in modules separate and organized.
>>
>>>>> - The tests will be grouped logically into suites or categories.
>>>>> Each
>>>>> individual test will fall in one of these suites.
>>>
>>>> Not sure of your usage of the word "test" in this sentence.  In  
>>>> junit
>>>> terms is that TestSuite, TestCase, or individual test method.  Can
>>>> you clarify?
>>>
>>> I meant TestCase. For. eg, we could have a TestSuite called,  
>>> "System"
>>> which will have test cases from many different modules. We could say
>>> that these form the core set of tests. If the System suite  
>>> passed, we
>>> have somewhat of a stable binary with the caveat that all functions
>>> may not work.
>>
>> That is much clearer to me, thanks.  I do like the sort of parent
>> module name you came up with of "System" too -- it's a keeper.
>>
>> At this point, I will note that it is possible put a single
>> SuperServerSystemTest.java TestSuite in the SuperServer assemblies
>> module (for example) that adds only the tests from the many different
>> test modules that apply to that assembly.
>>
>>> In summary, the cons of running the itests "on" assemblies is  
>>> that it
>>> goes against the m2 lifecycle. And even though integration-test  
>>> is an
>>> m2 lifecycle phase, we are not exploiting it's usage but calling it
>>> explicity again. The same has to be done for the deploy phase too.
>>
>> You captured that quite well.
>>
>> It occurred to me while writing a sentence above that there is no
>> clear distinction between "on" and "during".  In all cases you are
>> quite literally running the tests on the assembly.  The better
>> distinction is whether or not you wish to run them "during" it's
>> lifecycle or "after" in the lifecycle of a separate module.
>>
>> -David
>>
>

Re: Test strategy -- itests and default database

[David Blevins <da...@visi.com>]

On Feb 21, 2006, at 9:15 PM, Dain Sundstrom wrote:

> On Feb 21, 2006, at 5:28 PM, David Blevins wrote:
>
>> On Feb 21, 2006, at 2:00 PM, Prasad Kashyap wrote:
>>
>>> True. The itests setup (infrastructure) which was broken by the move
>>> has been restored. Itests can now be   plugged in and run
>>> successfully. While some of the old itests pass successfully,  
>>> some of
>>> them fail. The ones that fail are the ones that depended on the
>>> default-datasource.
>>>
>>> Around last Thu, I learnt from Dain (on the IRC)  that he'd be
>>> creating a new default datasource to get those tests to pass too. I
>>> don't know what the ETA on that is.
>>>
>>
>> Dain, is that something you'd get to in the next week (guessing  
>> not with the config changes)?
>
> Nope.  It got shelved with when I started the configId work.
>

Ok.  Good to know.

Thanks,
David

Re: Test strategy -- itests and default database

[Dain Sundstrom <da...@iq80.com>]

On Feb 21, 2006, at 5:28 PM, David Blevins wrote:

> On Feb 21, 2006, at 2:00 PM, Prasad Kashyap wrote:
>
>> True. The itests setup (infrastructure) which was broken by the move
>> has been restored. Itests can now be   plugged in and run
>> successfully. While some of the old itests pass successfully, some of
>> them fail. The ones that fail are the ones that depended on the
>> default-datasource.
>>
>> Around last Thu, I learnt from Dain (on the IRC)  that he'd be
>> creating a new default datasource to get those tests to pass too. I
>> don't know what the ETA on that is.
>>
>
> Dain, is that something you'd get to in the next week (guessing not  
> with the config changes)?

Nope.  It got shelved with when I started the configId work.

-dain

Re: Test strategy -- itests and default database

[Prasad Kashyap <go...@gmail.com>]

Hi David,

No I didn't make a list of the ones that work and the ones that don't.
But now I will soon.

Cheers
Prasad

On 2/21/06, David Blevins <da...@visi.com> wrote:
> On Feb 21, 2006, at 2:00 PM, Prasad Kashyap wrote:
>
> > True. The itests setup (infrastructure) which was broken by the move
> > has been restored. Itests can now be   plugged in and run
> > successfully. While some of the old itests pass successfully, some of
> > them fail. The ones that fail are the ones that depended on the
> > default-datasource.
> >
> > Around last Thu, I learnt from Dain (on the IRC)  that he'd be
> > creating a new default datasource to get those tests to pass too. I
> > don't know what the ETA on that is.
> >
>
> Dain, is that something you'd get to in the next week (guessing not
> with the config changes)?
>
> Prasad, do you know which test suites pass and which fail?  If we
> could figure that out we could comment out the ones that fail and get
> the itests running as part of the build again.  They're commented out
> now cause they cause the build to fail, which is bad news as someone
> will just break the infrastructure again without knowing it.
> Especially with all the maven2 conversion stuff going on.
>
> Thanks,
>
> -David
>
> > On 2/21/06, David Blevins <da...@visi.com> wrote:
> >> On Jan 29, 2006, at 6:12 AM, Prasad Kashyap wrote:
> >>> I would like to propose the following test strategy.
> >>>
> >>> 1. Fix existing openejb itests such that they can be reintegrated
> >>> back
> >>> into the builds.
> >>
> >> On Feb 9, 2006, at 9:10 AM, Prasad Kashyap wrote:
> >>
> >>> I have completed items 1 and 3 of the test strategy outlined above.
> >>> With that we now have the geronimo-deployment-plugin in maven 2.
> >>>
> >>
> >> Doesn't seem like item 1 was ever really checked off the list.  I
> >> just noticed the itests are still broken because of the whole default
> >> database issue.
> >>
> >> Where did we leave off on how to get them running again?  I remember
> >> some chatter on whether or not there should be a default database,
> >> etc.  But I also remember some IRC talk about just adding a connector
> >> to the itests to make them run.
> >>
> >> -David
> >>
> >
>
>

Re: Test strategy -- itests and default database

[David Blevins <da...@visi.com>]

On Feb 21, 2006, at 2:00 PM, Prasad Kashyap wrote:

> True. The itests setup (infrastructure) which was broken by the move
> has been restored. Itests can now be   plugged in and run
> successfully. While some of the old itests pass successfully, some of
> them fail. The ones that fail are the ones that depended on the
> default-datasource.
>
> Around last Thu, I learnt from Dain (on the IRC)  that he'd be
> creating a new default datasource to get those tests to pass too. I
> don't know what the ETA on that is.
>

Dain, is that something you'd get to in the next week (guessing not  
with the config changes)?

Prasad, do you know which test suites pass and which fail?  If we  
could figure that out we could comment out the ones that fail and get  
the itests running as part of the build again.  They're commented out  
now cause they cause the build to fail, which is bad news as someone  
will just break the infrastructure again without knowing it.   
Especially with all the maven2 conversion stuff going on.

Thanks,

-David

> On 2/21/06, David Blevins <da...@visi.com> wrote:
>> On Jan 29, 2006, at 6:12 AM, Prasad Kashyap wrote:
>>> I would like to propose the following test strategy.
>>>
>>> 1. Fix existing openejb itests such that they can be reintegrated  
>>> back
>>> into the builds.
>>
>> On Feb 9, 2006, at 9:10 AM, Prasad Kashyap wrote:
>>
>>> I have completed items 1 and 3 of the test strategy outlined above.
>>> With that we now have the geronimo-deployment-plugin in maven 2.
>>>
>>
>> Doesn't seem like item 1 was ever really checked off the list.  I
>> just noticed the itests are still broken because of the whole default
>> database issue.
>>
>> Where did we leave off on how to get them running again?  I remember
>> some chatter on whether or not there should be a default database,
>> etc.  But I also remember some IRC talk about just adding a connector
>> to the itests to make them run.
>>
>> -David
>>
>

Re: Test strategy -- itests and default database

[Prasad Kashyap <go...@gmail.com>]

True. The itests setup (infrastructure) which was broken by the move
has been restored. Itests can now be   plugged in and run
successfully. While some of the old itests pass successfully, some of
them fail. The ones that fail are the ones that depended on the
default-datasource.

Around last Thu, I learnt from Dain (on the IRC)  that he'd be
creating a new default datasource to get those tests to pass too. I
don't know what the ETA on that is.

Cheers
Prasad

On 2/21/06, David Blevins <da...@visi.com> wrote:
> On Jan 29, 2006, at 6:12 AM, Prasad Kashyap wrote:
> > I would like to propose the following test strategy.
> >
> > 1. Fix existing openejb itests such that they can be reintegrated back
> > into the builds.
>
> On Feb 9, 2006, at 9:10 AM, Prasad Kashyap wrote:
>
> > I have completed items 1 and 3 of the test strategy outlined above.
> > With that we now have the geronimo-deployment-plugin in maven 2.
> >
>
> Doesn't seem like item 1 was ever really checked off the list.  I
> just noticed the itests are still broken because of the whole default
> database issue.
>
> Where did we leave off on how to get them running again?  I remember
> some chatter on whether or not there should be a default database,
> etc.  But I also remember some IRC talk about just adding a connector
> to the itests to make them run.
>
> -David
>

Re: Test strategy -- itests and default database

[David Blevins <da...@visi.com>]

On Jan 29, 2006, at 6:12 AM, Prasad Kashyap wrote:
> I would like to propose the following test strategy.
>
> 1. Fix existing openejb itests such that they can be reintegrated back
> into the builds.

On Feb 9, 2006, at 9:10 AM, Prasad Kashyap wrote:

> I have completed items 1 and 3 of the test strategy outlined above.
> With that we now have the geronimo-deployment-plugin in maven 2.
>

Doesn't seem like item 1 was ever really checked off the list.  I  
just noticed the itests are still broken because of the whole default  
database issue.

Where did we leave off on how to get them running again?  I remember  
some chatter on whether or not there should be a default database,  
etc.  But I also remember some IRC talk about just adding a connector  
to the itests to make them run.

-David