Many Test classes or one Test class with many methods?

Question

I have a PersonDao that I'm writing unit tests against.

There are about 18-20 methods in PersonDao of the form -

    getAllPersons() 
    getAllPersonsByCategory()
    getAllPersonsUnder21() etc

My Approach to testing this was to create a PersonDaoTest with about 18 test methods testing each of the method in PersonDao

Then I created a PersonDaoPaginationTest that tested these 18 methods by applying pagination parameters.

Is this in anyway against the TDD best practices? I was told that this creates confusion and is against the best practices since this is non-standard. What was suggested is merging the two classes into PersonDaoTest instead.

As I understand is, the more broken down into many classes your code is, the better, please comment.

Answer 1

The fact that you have a set of 18 tests that you are going to have to duplicate to test a new feature is a smell that suggests that your PersonDao class is taking on multiple responsibilities. Specifically, it appears to be responsible both for querying/filter and for pagination. You may want to take a look at whether you can do a bit of design work to extract the pagination functionality into a separate class which could then be tested independently.

But in answer to your question, if you find that you have a class that you want to remain complex, then it's perfectly fine to use multiple test classes as a way of organizing a large number of tests. @Gishu's answer of grouping tests by their setup is a good approach. @Ryan's answer of grouping by "facets" or features is another good approach.

Answer 2

Can't give you a sweeping answer without looking at the code... except use whatever seems coherent to you and your team.

I've found that grouping tests based on their setup works out nicely in most cases. i.e if 5 tests require the same setup, they usually fit nicely into a test-fixture. if the 6th test requires a different setup (more or less) break it out into a separate test fixture.

This also leads to test-fixtures that are feature-cohesive (i.e. tests grouped on feature), give it a try. I'm not aware of any best practice that says you need to have one test class per production class... in practice I find I have n test classes per production classes, the best practice would be to use good names and keep related tests close (in a named folder).

Answer 3

My 2 cents: when you have a large class like that that has different "facets" to it, like pagination, I find it can often make for more understandable tests to not pack them all into one class. I can't claim to be a TDD guru, but I practice test-first development religiously, so to speak. I don't do it often, but it's not exactly rare, either, that I'll write more than a single test class for a particular class. Many people seem to forget good coding practices like separation of concerns when writing tests, though. I'm not sure why.