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
