[sip-comm-dev] Slickless tests - proposed change


#1

Emil,

I've been thinking about our previous discussion - under the topic "NPE in MclStorageManager".

I feel the set up for some of our unit tests is so complex that it is very difficult to walk cold into a problem and start writing new test cases to expose a bug. If it isn't easy to write tests, then most people won't write them.

Of course, many logic paths cannot be tested without a significant envelope of support software, usually including felix. However, many classes have methods whose corner cases could be tested and debugged under a much simpler environment. I've been thinking and developing a change that would enable this additional mode of development.

I have extended the concept behind your testing.properties property called TEST_LIST. I've defined a new property called SLICKLESS_TEST_LIST that defines all the slickless test classes.

SlicklessTests runs under felix and executes the existing slickless test classes using their hard-coded names. I have modified SlicklessTests to use the new property instead. This means it is very easy for someone to incorporate a new test class that can be run or debugged outside felix. This has the added advantage that when you run a full set of tests, the SlicklessTests runner picks up ALL these slickless tests and so they automatically appear in the xml/html test results reports.

I have also modified the SlicklessTests class so that it can run those tests outside felix - provided they don't actually require felix. This logic is a bit primitive, but I'm trying not to run too fast until I can walk.

I've modified the existing test target in the build to pick up the new properties list and so allow SlicklessTests to discover its subordinate test classes.

I've also added a new build target (a bit primitive at the moment) to run the SlicklessTests under jUnit (i.e. without felix). It either runs the default set from testing.properties, or allows you to over-ride via -Dtest.name.

I'd like to commit these changes before I develop any further. I want to add a netbeans target to debug a specific slickless test. Also, my current logic requires a fully-qualified package name for the test class and I wonder whether I can use simple classnames (without having to re-invent felix, of course!)

Once I've got this infrastructure working, I want to get back to the original problem!! I want to write some new low-level (non-felix) unit tests that expose the NPE in the MclStorageManager call stack.

What do you think?

Brian

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Emil,

I realise you are busy, but I am going to run out of spare time very soon and I want to make some progress on this issue.

My proposal was intended to be a "no brainer yes". I only asked your opinion because of my previous misunderstanding over the testing.properties.template change, and also your very wise advice about the MclContactList NPE bypass.

If you can't quickly spot a snag in my proposal, just let me know. The change is INTENDED to be transparent to all users who are not running a modified testing.properties, and I think svn update will merge the change for those who have local copies.

Regards,

Brian

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hey Brian,

I guess I must have missed your original mail, apologies.

So getting to the point, I think your change does make sense and see no
reason not to commit it. Let's hope it would boost test writing.

Cheers
Emil

Brian Burch wrote:

···

Emil,

I realise you are busy, but I am going to run out of spare time very
soon and I want to make some progress on this issue.

My proposal was intended to be a "no brainer yes". I only asked your
opinion because of my previous misunderstanding over the
testing.properties.template change, and also your very wise advice about
the MclContactList NPE bypass.

If you can't quickly spot a snag in my proposal, just let me know. The
change is INTENDED to be transparent to all users who are not running a
modified testing.properties, and I think svn update will merge the
change for those who have local copies.

Regards,

Brian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Emil Ivov wrote:

I guess I must have missed your original mail, apologies.

So getting to the point, I think your change does make sense and see no
reason not to commit it. Let's hope it would boost test writing.

Thanks for your confidence - sorry to nag!

I'll commit the changes soon.

Brian

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net