One Test-Class per method?

Question

since today I have used the pattern to create one test class per class. For example the class "Foo" with the methods "DoSomething" and "DoNothing" had one test class called "FooTests".

Now I have heard about creating one test class for every method. For the previous example this would mean I create two new classes called "DoSomethingTests" and "DoNothingTests" instead of the class "FooTests".

Is this a commonly used pattern and should I switch to this one, or is this furthermore an anti pattern?

Answer 1

My personal opinion is this: you'll create test classes in such a way that's logical and easy to maintain. Now if you have two methods very closely related I don't see why you'll create two classes. One more thing to consider how many test methods you have. You don't want to have a huge test class. Eventually you'll also have to maintain the test classes, so treat them like your regular code base.

Answer 2

I can not see the reason of introducing test classes for each and every methods. Honestly, I've never seen this kind of test strategy.

Of course, you can break apart your test classes if you have reason for it. You can extract common parts of your tests in separated helper classes. In some cases inheritance between test classes is also reasonable.

There is no difference between the test code and production code. Your test code should be clear, readable and maintainable. I think the "One Test-Class per method" ideology can ruin it.