aspose file tools*
The moose likes Testing and the fly likes JUnit : use case testing VS testing per method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Testing
Bookmark "JUnit : use case testing VS testing per method" Watch "JUnit : use case testing VS testing per method" New topic
Author

JUnit : use case testing VS testing per method

Vladas Razas
Ranch Hand

Joined: Dec 02, 2003
Posts: 385
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
Ranch Hand

Joined: Dec 02, 2003
Posts: 385
Of course, this is my particular case. I got lots of simple classes with utility methods, that are better tested per method..
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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().

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


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Vladas Razas
Ranch Hand

Joined: Dec 02, 2003
Posts: 385
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
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JUnit : use case testing VS testing per method