Unit testing - one test class/method, or test class/class

[Edvard Majakari]

"John Roth" <newsgroups at jhrothjr.com> writes:

> I tend to write one test class per class, but that's
> just the way I got started. My feeling is that the
> methods in a test class should tell a story if you
> read the names in the order they were written,
> so I'd split the tests for a class into several
> classes if they had different stories to tell.

Well, that's one of the things I forgot to mention. Often I use

TestSomeClassA:
    # test for normal, legal inputs

TestSomeClassB:
    # test for extreme/border cases, still legal inputs

TestSomeClassC:
    # test cases with illegal input, eg. negative integer when only positive
    # inputs make sense etc.

Just like you said, they tell a bit different story each, so it probably
makes sense to separate those.
   
>
> John Roth
>
> "Edvard Majakari" <edvard+news at majakari.net> wrote in message
> news:87y8ddywr9.fsf at titan.staselog.com...
>>
>> Hi,
>>
>> I just found py.test[1] and converted a large unit test module to py.test
>> format (which is actually almost-no-format-at-all, but I won't get there
>> now). Having 348 test cases in the module and huge test classes, I started
>> to think about splitting classes. Basically you have at least three
>> obvious
>> choises, if you are going for consistency in your test modules:
>>
>> Choise a:
>>
>> Create a single test class for the whole module to be tested, whether it
>> contains multiple classes or not.
>>
>> ...I dont think this method deserves closer inspection. It's probably
>> rather
>> poor method to begin with. With py.test where no subclassing is required
>> (like in Python unittest, where you have to subclass unittest.TestCase)
>> you'd probably be better off with just writing a test method for each
>> class
>> and each class method in the module.
>>
>> Choise b:
>>
>> Create a test class for each class in the module, plus one class for any
>> non-class methods defined in the module.
>>
>> + Feels clean, because each test class is mapped to one class in the
>>   module
>> + It is rather easy to find all tests for given class
>> + Relatively easy to create class skeleton automatically from test module
>>  and the other way round
>>
>> - Test classes get huge easily
>> - Missing test methods are not very easy to find[2]
>> - A test method may depend on other tests in the same class
>>
>> Choise c:
>>
>> Create a test class for each non-class method and class method in the
>> tested
>> module.
>>
>> + Test classes are small, easy to find all tests for given method
>> + Helps in test isolation - having separate test class for single method
>>  makes tested class less dependent of any other methods/classes
>> + Relatively easy to create test module from existing class (but then you
>>  are not doing TDD!) but not vice versa
>>
>> - Large number of classes results in more overhead; more typing, probably
>>  requires subclassing because of common test class setup methods etc.
>>
>> What do you think, any important points I'm missing?
>>
>> Footnotes:
>> [1]  In reality, this is a secret plot to advertise py.test, see
>>     http://codespeak.net/py/current/doc/test.html
>>
>> [2] However, this problem disappears if you start with writing your tests
>>    first: with TDD, you don't have untested methods, because you start by
>>    writing the tests first, and end up with a module that passes the tests
>>
>>
>> --
>> # Edvard Majakari Software Engineer
>> # PGP PUBLIC KEY available    Soli Deo Gloria!
>> One day, when he was naughty, Mr Bunnsy looked over the hedge into Farmer
>> Fred's field and it was full of fresh green lettuces. Mr Bunnsy, however,
>> was
>> not full of lettuces. This did not seem fair.  --Mr Bunnsy has an
>> adventure

-- 
# Edvard Majakari		Software Engineer
# PGP PUBLIC KEY available    	Soli Deo Gloria!

$_ = '456476617264204d616a616b6172692c20612043687269737469616e20'; print
join('',map{chr hex}(split/(\w{2})/)),uc substr(crypt(60281449,'es'),2,4),"\n";