"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 severa
aurora <[EMAIL PROTECTED]> writes:
> What I really want to bring up is your might want to look at refactoring
> your module in the first place. 348 test cases for one module sounds like a
> large number. That reflects you have a fairly complex module to be tested
> to start with. Often the bigges
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.
Jo
I do something more or less like your option b. I don't think there is any
orthodox structure to follow. You should use a style that fit your taste.
What I really want to bring up is your might want to look at refactoring
your module in the first place. 348 test cases for one module sounds lik
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 obv
