You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2006/01/13 18:55:46 UTC
What should build, was: Build problem
Jean-Sebastien Delfino wrote:
>>
>> - I think we need to establish a policy that the build should never
>> break and in particular the acceptance test suite should run before each
>> commit. The sooner we get a stable build the sooner all of us can
>> engage with all the work we have ahead of us.
>>
I thought we split these to allow some stuff to break temporarily.
IOW, normal unit/integration tests would run automatically as part of a
normal build and were supposed to work for every commit. The goal is to
produce a build that is "good enough" for the developers to work with -
i.e. the default build works every time, no excuses.
The acceptance tests were meant to replicate scenarios users would see
and were meant to be run before any release/distribution e.g. before
posing an "unstable" build somewhere. Eventually these would grow (e.g.
to include compliance tests) and take so long to run that it would be
impractical to run them for every commit.
--
Jeremy
Re: What should build, was: Build problem
Posted by Jim Marino <jm...@myroma.net>.
I thought about deleting that one a few days ago but was afraid :).
I think bringing some of the tests down from the acceptance to unit
tests would be good. Also, I think the fact we are afraid to delete
files like this points to an additional problem in the code (beyond
not having proper test coverage): sometimes we refer to classes using
Strings rather than Foo.class.getName(). We did this in a couple
areas where there were forward references to projects (for example,
the Java implementation builder being referenced from
TuscanyModuleComponentContextImpl). With the introduction of
autowiring and system components, there should no longer be a need
for this. For example, AggregateComponentContextImpl does not do this
anymore, as bootstrap builders are either passed to the runtime or
configured as system components and accessed through a
ConfigurationContext autowire.
We should comb through the code as we refactor and and either
substitute direct class references or use autowiring when we cut over
to using AggregateComponentContexts.
Jim
On Jan 13, 2006, at 10:34 AM, Jean-Sebastien Delfino wrote:
> It's okay Jim, no problem :) I'm pretty sure all of us are going to
> break our builds over the next few weeks... BTW I just deleted
> AxisWebAppLifecycleListener (I'll send more details on a different
> thread), ran the build, crossing my fingers now hoping that I
> didn't break anything :)
>
> --
> Jean-Sebastien
>
>
>
> Jim Marino wrote:
>
>> Nevertheless it was my mistake for deleting the file in this case.
>>
>>
>> On Jan 13, 2006, at 9:55 AM, Jeremy Boynes wrote:
>>
>>
>>> Jean-Sebastien Delfino wrote:
>>>
>>>
>>>
>>>>>
>>>>> - I think we need to establish a policy that the build should
>>>>> never
>>>>> break and in particular the acceptance test suite should run
>>>>> before each
>>>>> commit. The sooner we get a stable build the sooner all of us can
>>>>> engage with all the work we have ahead of us.
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> I thought we split these to allow some stuff to break temporarily.
>>>
>>> IOW, normal unit/integration tests would run automatically as
>>> part of a
>>> normal build and were supposed to work for every commit. The goal
>>> is to
>>> produce a build that is "good enough" for the developers to work
>>> with -
>>> i.e. the default build works every time, no excuses.
>>>
>>> The acceptance tests were meant to replicate scenarios users
>>> would see
>>> and were meant to be run before any release/distribution e.g. before
>>> posing an "unstable" build somewhere. Eventually these would grow
>>> (e.g.
>>> to include compliance tests) and take so long to run that it
>>> would be
>>> impractical to run them for every commit.
>>>
>>> --
>>> Jeremy
>>>
>>>
>>
>>
>
Re: What should build, was: Build problem
Posted by Jean-Sebastien Delfino <js...@apache.org>.
It's okay Jim, no problem :) I'm pretty sure all of us are going to
break our builds over the next few weeks... BTW I just deleted
AxisWebAppLifecycleListener (I'll send more details on a different
thread), ran the build, crossing my fingers now hoping that I didn't
break anything :)
--
Jean-Sebastien
Jim Marino wrote:
> Nevertheless it was my mistake for deleting the file in this case.
>
>
> On Jan 13, 2006, at 9:55 AM, Jeremy Boynes wrote:
>
>> Jean-Sebastien Delfino wrote:
>>
>>
>>>>
>>>> - I think we need to establish a policy that the build should never
>>>> break and in particular the acceptance test suite should run before
>>>> each
>>>> commit. The sooner we get a stable build the sooner all of us can
>>>> engage with all the work we have ahead of us.
>>>>
>>>>
>>
>>
>> I thought we split these to allow some stuff to break temporarily.
>>
>> IOW, normal unit/integration tests would run automatically as part of a
>> normal build and were supposed to work for every commit. The goal is to
>> produce a build that is "good enough" for the developers to work with -
>> i.e. the default build works every time, no excuses.
>>
>> The acceptance tests were meant to replicate scenarios users would see
>> and were meant to be run before any release/distribution e.g. before
>> posing an "unstable" build somewhere. Eventually these would grow (e.g.
>> to include compliance tests) and take so long to run that it would be
>> impractical to run them for every commit.
>>
>> --
>> Jeremy
>>
>
>
Re: What should build, was: Build problem
Posted by Jim Marino <jm...@myroma.net>.
Nevertheless it was my mistake for deleting the file in this case.
On Jan 13, 2006, at 9:55 AM, Jeremy Boynes wrote:
> Jean-Sebastien Delfino wrote:
>
>
>>>
>>> - I think we need to establish a policy that the build should never
>>> break and in particular the acceptance test suite should run
>>> before each
>>> commit. The sooner we get a stable build the sooner all of us can
>>> engage with all the work we have ahead of us.
>>>
>>>
>
>
> I thought we split these to allow some stuff to break temporarily.
>
> IOW, normal unit/integration tests would run automatically as part
> of a
> normal build and were supposed to work for every commit. The goal
> is to
> produce a build that is "good enough" for the developers to work
> with -
> i.e. the default build works every time, no excuses.
>
> The acceptance tests were meant to replicate scenarios users would see
> and were meant to be run before any release/distribution e.g. before
> posing an "unstable" build somewhere. Eventually these would grow
> (e.g.
> to include compliance tests) and take so long to run that it would be
> impractical to run them for every commit.
>
> --
> Jeremy
>
Re: What should build, was: Build problem
Posted by Jean-Sebastien Delfino <js...@apache.org>.
I agree with breaking temporarily a big compliance or function test suite.
I think we need to split our current "acceptance" test suite into two
branches (not necessarily right now but in a near future):
a) a set of basic Build Verification Tests that verify that our runtime
can run basic scenarios with Tomcat, Web Services, JSPs and POJOs, this
should take just a few minutes max to run
b) a much bigger Function Verification Test suite that will grow over
time and this is what we'll run before any release/distribution.
IMO what we have in our current acceptance test suite covers (a) right
now (in other words it looks really like a BVT to me) and I'd like to
try to keep it working at all times. For example if our runtime does not
even start in Tomcat, then there's really not much you can do with
it... and this will slow down all of us.
What do people in the group think?
--
Jean-Sebastien
Jeremy Boynes wrote:
> Jean-Sebastien Delfino wrote:
>
>
>>> - I think we need to establish a policy that the build should never
>>> break and in particular the acceptance test suite should run before each
>>> commit. The sooner we get a stable build the sooner all of us can
>>> engage with all the work we have ahead of us.
>>>
>>>
>
>
> I thought we split these to allow some stuff to break temporarily.
>
> IOW, normal unit/integration tests would run automatically as part of a
> normal build and were supposed to work for every commit. The goal is to
> produce a build that is "good enough" for the developers to work with -
> i.e. the default build works every time, no excuses.
>
> The acceptance tests were meant to replicate scenarios users would see
> and were meant to be run before any release/distribution e.g. before
> posing an "unstable" build somewhere. Eventually these would grow (e.g.
> to include compliance tests) and take so long to run that it would be
> impractical to run them for every commit.
>
> --
> Jeremy
>
>
>
Re: What should build, was: Build problem
Posted by Jim Marino <jm...@myroma.net>.
On Jan 13, 2006, at 9:55 AM, Jeremy Boynes wrote:
> Jean-Sebastien Delfino wrote:
>
>
>>>
>>> - I think we need to establish a policy that the build should never
>>> break and in particular the acceptance test suite should run
>>> before each
>>> commit. The sooner we get a stable build the sooner all of us can
>>> engage with all the work we have ahead of us.
>>>
>>>
>
>
> I thought we split these to allow some stuff to break temporarily.
>
> IOW, normal unit/integration tests would run automatically as part
> of a
> normal build and were supposed to work for every commit. The goal
> is to
> produce a build that is "good enough" for the developers to work
> with -
> i.e. the default build works every time, no excuses.
I tend to agree with Jeremy, particularly when we get to deploying on
other platforms besides Tomcat, since running all of the acceptance
tests would be unwieldy (and also assumes I have Tomcat set up). It
seems like what we need to do is have better unit test coverage to
check this type of stuff. For example, the
TomcatServerLifecycleListener is not referenced or unit tested so the
core build doesn't break, even though it is critical.
>
> The acceptance tests were meant to replicate scenarios users would see
> and were meant to be run before any release/distribution e.g. before
> posing an "unstable" build somewhere. Eventually these would grow
> (e.g.
> to include compliance tests) and take so long to run that it would be
> impractical to run them for every commit.
>
> --
> Jeremy
>