[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster-devel] Testsuite.
Peter Bennett wrote:
I have noted various things about the testsuite...
Most of them quit a while ago...
Going over it again in detail there are many issues that need to be
I have some questions about some of them...
Some may be config errors on my part, others like C++ tests I am not set
up for yet... I could do with some help compiling the C++ stuff but that
can wait until later.
Firstly this error message.
[Nov 24, 2003 10:59:11 PM [33;40mWARN [0m CbQueueProperty] The queue
relating attribute is invalid 'callback_somequeueid', setting to session
I fixed this in the development branch (line 92 of I_QueueTest).
I found the code that generates this warning in I_QueueTestThat's *not OK* since these make two different things. If you do a new
Global you instantiate a new object while if you use Global.instance()
you get the first instance created (no new object is created). I fixed
the stack trace issue: you will not get any warning anymore when using
new Global (dev branch).
For the life of me I could not find the string somequeueid
using grep... My bad as grep is case sensitive and as it appears in the
source it is SomeQueueId.
Next: Global initialisation.
java.lang.Exception: Stack trace
[Nov 24, 2003 10:59:41 PM [31;40mERROR[0m I_MapTest] PLEASE UPDATE
I have fixed other classes that use new Global to be Global.instance()
however the classes that use engine.Global I am not sure of...
util.Global is fine.
How do I fix the code in I_MapTest to set up the Global needed for the
tests? Is it using the wrong one? i.e engine.Global should be replaced
with util.Global and initialised that way.I_Map uses an engine global while the testsuite uses a util.Global. This
is sufficient however for the sake of the test.
That will do for the moment...
There are more but I need to check them as much as I can first before
asking dumb questions :)
Its OK to look at the warnings and errors in the testsuite, however I
think its better to primarly focus on the asserts since many warnings
and exceptions could be justificated when testing (after all many of the
tests are there to test the alternative case).
If there are no asserts in the tests you can assume that the code you
are testing is OK.