"John Roth" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>>
>> 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";
--
http://mail.python.org/mailman/listinfo/python-list
