JUnit tests guidelines

[HS Thomas]

I have an interface that I want to write some tests against.
Eclipse has kindly generated some test stubs with TODOs marked against the testmethods.
How do I structure the tests ? Where do I start and how do I make sure the tests are at the right granularity.
I don't want to spend endless time re-writing my tests over and over again.
regards

[Ilja Preuss]

Originally posted by HS Thomas:
I have an interface that I want to write some tests against.
Eclipse has kindly generated some test stubs with TODOs marked against the testmethods.
How do I structure the tests ? Where do I start and how do I make sure the tests are at the right granularity.

First, throw away the autogenerated test stubs. You don't want to test methods - you do want to test behaviour.
Then think about a simple usage scenario for your class. Write a test for that. Iterate until you have confidence in the correctness of your class. (If you'd tell us more about your interface, we could help you with this.)
BTW, I find that it's much easier to come up with tests working test-driven - that is, writing the tests first, before writing the production code.

I don't want to spend endless time re-writing my tests over and over again.

This typically just does not happen to me - can't tell you exactly why.
I would advice to simply try it out. If you encounter problems, ask for help (here or at the junit mailing list).
Regards, Ilja

[HS Thomas]

Thanks Illja.
Well I thought I'd build my tests as follows:
Start with the low-level Database interface which has the usual methods.

public interface DatabaseInterface
{
public String[] read(String  recordID) throws DatabaseException;
public void update(String  recordID, String[] data) throws DatabaseException ;
public void delete(String  recordID) throws DatabaseException ;
public String[] search(String[] criteria);
public long lock(String  recordID)   throws DatabaseException;
public void unlock(String  recordID) throws DatabaseException;
public void commit() throws DatabaseException; 
}

Note recordID is a unique record identifier field with type String because we have a security system where keys are hashed to a character value.
After that I want to test concurrency, security, and simple transactions, then distributed tests.
And finally build a usecase scenario test, and be confident that it will pass basic system processing.
Basic system processing would be e.g .
Search for objects that match certain criteria.
Read selected object.
Perform update on selected object.
Commit transaction.
Use Case scenario would be :

Customer A requests service B(basic car service) and D (optional extras).
Resources XY(parts), DD(labour) and EF (block of time) are reserved to fulfill requests.
Customer pays for service B before D can be started.
Customer pays for service D.
Customer requests service E (finance).

My plan is to start with the low-level tests.
Then write new tests for the higher level functions.
I could re-use my tests and adapt them for the higher level functions but I may need the low-level ones again later so I prefer to write new ones.
Should I write ALL these tests before I even start writing any code?
regards
[ July 19, 2003: Message edited by: HS Thomas ]

[HS Thomas]

I think you'd suggest tackling it feature by feature :-
Customer requests service (car service, optional extras,finance);
I've already eliminated duplication here
and have come up with one class :
CustomerService
Now to write a TestCase :-

import junit.framework.TestCase;
public class CustomerServiceTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(CustomerServiceTest.class);
} 
 

Additional methods in the CustomerService class are:
public Service requestService(ServiceType stype, TimeBlock block );
createCustomerService(ServiceType stype, TimeBlock block);
Adding the tests for the above

 final public void testRequestService() {

}
final public void testCreateCustomerService() {

}

Now I have three additional classes Service(abstract or super), ServiceType which extends Service ,TimeBlock.
This will probably refactor into 4 tables
CustomerService,Service,ServiceType and TimeBlock. Cannot see any possibilities for de-normalising into fewer tables as yet.
Okay I can see the possibilities of developing the Tests along with the design. And code until the final test has been written !
That's going to be a tough habit to break.
The next steps would be to write the code to implement the feature , and test it as you go along, refactoring along the way.
It sounds plausible but I still have to try it. Correct me, please, where I have gone wrong!
regards
[ July 19, 2003: Message edited by: HS Thomas ]
[ July 24, 2003: Message edited by: HS Thomas ]

[Ilja Preuss]

In fact I'd suggest tackling it test by test.
And remember that you will want to test behaviour, not methods. You will probably have several test cases per methods, and tests which will test the interaction of several methods.
What is the *simplest* usage scenario you can think of for your CustomerService class? Often it is good to start with an overly simplistic case and build up on that - something like sorting an empty list. Can you think of something like that?

[HS Thomas]

Thanks Illja. I need to think on this a bit.
Short of falling back on my original plan of attack I haven't come up with anything new.
I think what's missing is focussing on OO design
i.e behavior, rather than use-cases and data tables.
... and,as you say, starting simply..
regards
[ July 22, 2003: Message edited by: HS Thomas ]

[HS Thomas]

quote:
--------------------------------------------------------------------------------
I don't want to spend endless time re-writing my tests over and over again.
--------------------------------------------------------------------------------
This typically just does not happen to me - can't tell you exactly why.

You are too modest!
regards

[HS Thomas]

What is the *simplest* usage scenario you can think of for your CustomerService class?

Oh! I think you mean tests like :-
1: testCustomerHasSelectedNoServices();
2: testCustomerHasRequestedOneService();
3: testCustomerHasRequestedManyServices();
I could then start with building testGetCustomerServiceRequest() against the database to check that it returns no, one and finally many CustomerService data objects;
Then move on to testing the User Interface, test by test.
I suppose I cannot code the User Interface just yet either.
In order for the writing of the Test Cases to flow freely, I must at least have completed the design to include use cases, domain models, interaction diagrams and class diagrams.
Or do the Tests come before producing all Design artifacts except use cases?
( I should really be avoiding duplication as test 3 is really test 2 run as many times as required. )
regards
[ July 24, 2003: Message edited by: HS Thomas ]

[Ilja Preuss]

Originally posted by HS Thomas:
Oh! I think you mean tests like :-
1: testCustomerHasSelectedNoServices();

Possibly. (Notice that I am currently only interested in the first test. The others will follow rather naturally.)
What could the test look like? Can you formulate it in a few lines of code?

I suppose I cannot code the User Interface just yet either.

I am not sure I do understand this. Can you please elaborate?

In order for the writing of the Test Cases to flow freely, I must at least have completed the design to include use cases, domain models, interaction diagrams and class diagrams.

Why? Remember, you only need to write the first, small test now. Do you really need all those diagrams for that?

Or do the Tests come before producing all Design artifacts except use cases?

The unit tests and the code are design artifacts, too - and in test driven development, they are the primary ones (well, the code always is).
If it makes you feel more comfortable, you can certainly scribble any additional diagram you'd like, but using TDD I find that most often I don't need more (and that in fact any diagram I do is wrong, anyways).

(I should really be avoiding duplication as test 3 is really test 2 run as many times as required.)

Yes. We will handle that by extracting the duplicated parts into there own unique places once they actually show up. It's much easier to remove already existing duplication than to remove anticipated duplication.

[Ilja Preuss]

Originally posted by Ilja Preuss:
This typically just does not happen to me - can't tell you exactly why.

Well, as I think about it, I *do* have some ideas:
- by writing the tests first, the classes' interfaces are more driven by client needs, less by their implementation details. This makes the interfaces - and therefore the tests, too - more stable.
- to easily unit test the classes, I need to decouple them quite well. So changes typically don't ripple through all the classes (and tests).
- by mercilessly refactoring my test classes, too - especially removing duplication - changes should only need to be done at single places.
Does that compute?
[ July 24, 2003: Message edited by: Ilja Preuss ]

[HS Thomas]

Thanks Illja. That does make sense. Just difficult to put into practice without practise.
By User Interface, I meant , the GUI. If I started testing from the GUI I'd have put in a test to ensure that they can't hit the Submit button unless a Service(s) has been selected from a drop-down list.
But this is the simplest test I can think of :

 
import junit.framework.TestCase;

public class CustomerServiceTest extends TestCase  {

protected String [] selection ;

public static void main(String[] args) {
junit.textui.TestRunner.run(CustomerServiceTest.class);
}
 
public void testCustomerHasSelectedNoService() throws Exception {

boolean expected= true; 
boolean result= (selection[0] == null); 
assertTrue(expected == result);
}

protected void setUp() throws Exception {
super.setUp();
selection = new String[10];
}

protected void tearDown() throws Exception {
super.tearDown();
}
}
 

And it runs with no Failures.
The only assumption I have made so far is that the selection is passed as a String [].
Oh!And that up to 10 selections are possible.
And that , if the first element is null, no selections have been made.
And how, oh how, is this documentation ?
It is a neatly encapsulated testable assertion, I grant you that.

regards
[ July 26, 2003: Message edited by: HS Thomas ]

[HS Thomas]

And how, oh how, is this documentation ?

I take that back. I read somewhere that these Tests would be sufficient documentation for programmers, systems testers and business stakeholders.
Since I am familiar with the response "believe nothing until the Tests prove it" from all, I have to accept this is sufficient documentation.
You'd still need user documentation, systems documentation and operations documentation.
regards
[ July 27, 2003: Message edited by: HS Thomas ]