I’m working on a backend for an open source Python ORM. The library includes a set of 450 test cases for each backend, all lumped into one giant test class.
To me, that sounds like a lot for one class, but I’ve never worked on a project that has 450 test cases (I believe this library has ~2000 test cases not including the test cases for each backend). Am I correct in feeling this is a bit on the high end (given that there’s not really any magic number above which you should break something up), or is it just not as big a deal for a test class to have so many tests?
And even if that’s not too many test cases, how would one go about refactoring an overly large test class? Most of my knowledge about refactoring is around making sure that tests are in place for the code that’s being refactored. I’ve never had to deal with a situation where it’s the tests themselves that need to be refactored.
EDIT: Previously, I had said that these were unit tests, which isn’t quite true. These are more appropriately termed integration tests.
450 tests in one class sounds like a lot, but how bad it is depends on how they are organized. If they all are truly independent of each other and the test class’ members, it may not be a big deal – other than it must be hard to locate a specific test.
On the other hand, if the test class has members that are used by only some of the tests and ignored by others, it’s a Test Smell called Obscure Test containing such Root Causes as General Fixture and Irrelevant Information (please note the jargon – I’ll get back to this).
There are several ways of organizing tests into classes. The most common patterns are Testcase Class per Class, Testcase Class per Feature and Testcase Class per Fixture.
How you structure tests is important not only while you are writing the tests, but also afterwards for maintainability reasons. For that reason alone, I’d tend to say that it would be a worthwhile effort refactoring your tests. In TDD, the test code base is (almost) as important as the real code base, and should be treated with the same kind of respect.
There’s a whole book about this subject, called xUnit Test Patterns: Refactoring Test Code that I can’t recommand enough. It contains a complete pattern language that deals with unit testing and TDD, and all the pattern names I’ve used here originates from it.