JUnit : use case testing VS testing per method

[Vladas Razas]

Hi,

What do you think about class testing, by using use case approach versus per method testing? Of course unit testing is for programmer to be sure he/she delivered working methods. If every method works then class must be good. On the other hand some functionality is split between few methods. I implement class where interaction between methods is important (but not too visible from outside, since methods use common fields in a class), but if I write testMethodA, testMethodB it either creates duplicate tests, or it doesn't reflect how I supposed those methods to be used. I think testOperationA, testOperationB would be more convenient for me, and also it would produce better code for fellow programmers to learn, how this class is supposed to be used.

So... what do you think?

Vladas

[Vladas Razas]

Of course, this is my particular case. I got lots of simple classes with utility methods, that are better tested per method..

[Lasse Koskela]

Originally posted by Vladas Razas:
What do you think about class testing, by using use case approach versus per method testing?

Use cases are too big for unit testing -- a use case is, by definition, in the realm of [o]functional testing[/i] and not unit testing.

Originally posted by Vladas Razas:
Of course unit testing is for programmer to be sure he/she delivered working methods. If every method works then class must be good.

I don't mean to come off as a nitpicking type but I'd like to draw attention to something:

Unit testing should not be thought of as a means to ensure that a class's methods work. Unit testing should be thought of as a means to ensure that a class does what it's supposed to do. Yes, that functionality manifests itself technically as a set of methods that your test code can call but you should keep in mind that even if all the tests that you write for those methods are passing, the class may still not be a "good" class.

Originally posted by Vladas Razas:
On the other hand some functionality is split between few methods.

Again, it's not about the methods. It's about the class's interface which may or may not consist of multiple methods. For example, it's perfectly valid to have an interface as follows and declare that begin() should be called before commit().

public interface Transaction {
    void begin();
    void commit();
}

Now, in testing some implementation of this interface, you'd eventually be calling both of these methods from within a single test. For example:

public class MyTransactionTest extends TestCase {
 
    public void testTransactionIsCommittedProperly() {
        Transaction tx = new MyTransactionImpl();
        tx.begin();
        // do something inside the transaction
        tx.commit();
        // assert that the things we did inside the transaction were
        // indeed committed properly
    }
 
    public void testTransactionIsRolledBackProperly() {
        Transaction tx = new MyTransactionImpl();
        tx.begin();
        // do something inside the transaction
        tx.rollback();
        // assert that the things we did inside the transaction were
        // not committed but rolled back instead
    }
}

[Vladas Razas]

Great reply, I was fooled by Pragmatic Unit testing book (the exact name I forgot) that said "it's good practice to call test methods by the name of method being tested, i.e. testMethodAAA". I took it to the letter and thought every test must test a method. As I understand we testing not use case, nor method but a piece of behaviour, i.e. concrete functionality. I hope I did get it correctly.
Huh, it's not even a second time I am being fooled by the book I have this problem taking something out of context and applying it too judiciously.

Thanks!
P.S. I sincerely hope I did get it right now.

[Lasse Koskela]

Originally posted by Vladas Razas:
As I understand we testing not use case, nor method but a piece of behaviour, i.e. concrete functionality.

Yes!

Originally posted by Vladas Razas:
Huh, it's not even a second time I am being fooled by the book I have this problem taking something out of context and applying it too judiciously.

I get that too. I pick up some idea from somewhere and go a bit too far with it just to find out that I should've stopped 10 minutes ago. Then again, that's alright. That's how you learn.