问题
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?
Thanks for you help.
回答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.
回答2:
The main advantage of creating one test class per production class is that it's simple and understandable. If you have Foo, you know for certain that all the unit tests for Foo can always be found in FooTest (or whatever your naming convention calls it. You are following a naming convention for the unit test class names, aren't you?)
For readability purposes, I recommend your team define a naming convention that helps identify the tests. For example, I might name one of the tests FooTest::DoSomething_ensureNullPointerThrowsException(). That way the reader knows not only it's a test for Foo::DoSomething(), but they also know it's testing for a null pointer exception.
In general, if something seems "wrong" or "hard to do"; if you think it would be easier to do something differently because your project just doesn't seem to mesh with the way everyone else does it; it's often due to violations of one or more of the OO design principles. Look deeply for the root cause: why am I struggling with issue X? Why does someone want want one test class per production method? Are there a hundred tests for each method and the developer thinks a change would keep them grouped together better? The real cause is likely that his methods have too much responsibility, or are overly complex. If his methods were simpler, he may find he needs perhaps only five or ten tests for each method.
回答3:
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.
回答4:
I think it is all about when to apply such a thing. I'd say that in general you should not be creating a test class per test method. I would recommend grouping methods with the same functionality (e.g. the methods in a single class) in a single test class. However, an exception might be an extremely complex method that requires dozens of tests to verify its behavior. In such a case a single test class might be useful. You have to be careful creating exceptions though, as this makes the way the code is structured less obvious.
来源：https://stackoverflow.com/questions/16589178/one-test-class-per-method