On Sep 11, 2006, at 3:57 AM, kelvin goodson wrote:
Now in the java world here's a nasty catch, one side effect of
this which,
given the way we run things, only occurs in a maven test run, and
not when
running junits in eclipse is that one unit test can affect a later
one. In
maven the tests are all run within one process invocation, and
therefore
share static variables, whereas we haven't as yet created top level
tests
that use the Junit suite approach to aggreating test case runs, so
we don't
see this symptom when running the tests individually. So a late
test in
maven might see an instance of TypeHelper.INSTANCE with a dynamic
version of
the SDO model created as a side effect of a previous test. I can
see a few
things we could do here, either specific to this case and/or as
general
project guidelines.
- change the way we create types to avoid this masking behaviour in
general
- put a special case catch into the XSD converter to permit
inclusion of
sdoModel.xsd and avoid this side effect?
- create an SDOUtil.reset(TypeHelper) method or some such, which
could be
called in the tear down method of test cases
- more generally implement classes that don't match the maven
filename rule
for test cases, which mimic the merging behaviour of the maven
test case
run, and then use this when running test cases outside of maven.
what do you think?
There is an option to surefire to run all tests individually by
forking new VM for every test. Turning this on generally tanks test
performance.
One of the guidelines for unit testing is that they should be
independent and it sounds like this setup violates this. To achieve
this some form of reset is needed for SDO, not only the TypeHelper
but any of the helpers that cache resources in statics. We will also
need this in the SCA runtime if we are going to be able to undeploy
composites that reference SDO types.
Need I say that this illustrates one way in which singletons are evil
and that in the long term SDO should move away from INSTANCE all
together :-)
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
