如何为同一方法命名不同的测试? [英] How to name different tests for the same method?

问题描述

如何命名具有多种不同流程的方法的测试?

How do I name tests for a method that has many different flows?

例如，假设我有一个方法process()，该方法根据对象的字段而表现不同:

For example, let's say I have a method, process(), which behaves differently based on an object's fields:

public void process () {

    if (this.someField1 == null) {
        doSomethingOne();
    else
        doSomethingTwo();

    if (this.someField2 == null) {
        doSomethingThree();
    else
        doSomethingFour();
}

此方法有四种不同的潜在结果.我假设我应该为100％的代码覆盖率编写四个不同的测试用例.我应如何命名这些测试用例?还是人们通常会制作一个巨大的测试用例?

There are four different potential outcomes from this method. I assume I should write four different test cases for 100% code coverage. Is there a standard practice/pattern for how I should name those test cases? Or do people normally make one giant test case?

推荐答案

命名测试时应实现一些目标.请记住，在运行多个测试时，如果由于更改而导致回归，则可能会看到许多失败的测试.然后，理想的情况是，通过失败和通过测试的模式，您可以立即(甚至无需进入代码或启动调试器)就可以推断出问题所在.

There are some goals that shall be achieved when naming tests. Keep in mind that when you run a number of tests, in case of regressions due to changes you may see a number of failing tests. Then, the ideal situation is, that from the pattern of failing and passing tests you can immediately (without even going into the code or starting a debugger) deduce what the problem is.

因此，您想从诊断输出(包括失败测试的名称)中了解

Therefore, from the diagnostic output (which includes the name of the failing tests) you would like to know

• 对于每个失败的测试，正在测试哪个类/方法.
• 测试失败的情况是什么.
• 预期结果是什么

在某种程度上，这已经由测试框架的默认输出提供.例如，您获得每个失败测试的文件名和类名.但是，即使您知道它是文件FooTest.java中的类FooTest，也仍然不太容易理解test15和test21的失败.此外，测试框架断言(如果失败)还指示期望值和实际值.对于某些测试，可能很清楚知道19是预期的，但20是实际结果.但是，知道预期输出为19(即第八个素数)可能会更有用.

To some extent this is already provided by the default output of the test frameworks. For example, you get the file names and class names for each failing test. But, even if you know it is class FooTest in file FooTest.java, then it is still not too enlightening to know that test15 and test21 are failing. Moreover, the test framework assertions - when failing - also indicate expected and actual values. For some tests it may be clear enough to learn that 19 was expected but 20 was the actual results. It may, however, be more helpful to know that the expected output is 19, being the eigth prime number.

解决上述问题的常见测试名称模式是:

A common pattern for test names that addresses the above point is:

<method under test>_<scenario being tested>_<expected outcome>

例如

process_noFieldsInitialized_shallDoOneAndThree

但是还有更多的命名约定，它们基本上针对相同的主题，但方式略有不同.

but there are some more naming conventions, which basically address the same topics but in slightly different ways.

也许值得一提的是，在这个方向上也有一条思路:不要考虑解释性强的测试名称，而是要使您的测试代码更具可读性，以便可以在测试代码中立即看到所有信息.对我而言，这不是矛盾:可以肯定，代码应该易于阅读.但是，代码在实现级别上并使用具体的值，而测试名称可以在语义/用户域级别上，并且可以描述抽象方案:想象一下，在测试某些功能foo时，您要测试foo会以高于42的数字被调用.在测试实现中，您必须选择一个数字，也许是43，但也许是50.但是，在您的测试名称中，您仍然可以清楚地表明测试的含义:foo_withArgumentAbove42_shallProvideTheAnswer.

It may be worth mentioning that there is also a line of thought in the direction: Instead of thinking about great explanatory test names, make your test code better readable such that all information can be seen in the test code immediately. For me, this is not a contradition: The code should be easy to read, for sure. But, the code is on the implementation level and uses concrete values, whereas the test name can be on semantic/user domain level and can describe the abstract scenario: Imagine that when testing some function foo you want to test the scenario that foo is called with some number above 42. In your test implementation you have to choose a number, maybe 43, but maybe 50. But, in your test name you can still make it clear what the test is about: foo_withArgumentAbove42_shallProvideTheAnswer.

现在，您要回答第二个问题:应该将所有四个方案都放在一个测试用例中，还是更笼统地说，应该将一种方法的所有测试都放入一个测试用例中.让我从上面重复一个目标:从失败和成功的测试用例的模式中，理想情况下，您应该应该能够立即推断出问题所在.这样得出的结论是，您应该针对不同的方面/场景进行不同的测试.在您的情况下，将有四个测试用例.如果一种情况失败，您将立即知道它是哪一种.如果将所有方案都放在一个测试用例中，那么之后您将不得不找出问题的实质所在.

Now, coming to your second question: Should you put all four scenarios into one test case, or, more generally, should all tests for one method go into one test case. Let me repeat the goal from above: From the pattern of failing and succeeding test cases you should ideally be able to deduce immediately what the problem is. This leads to the conclusion that you should have different tests for different aspects/scenarios. In your case, there would be four test cases. If one scenario fails, you will know immediately which one it was. If you put all scenarios in one test case, you will afterwards have to figure out what the problem actually was.

更新:有四个测试而不是一个测试可能意味着某些代码重复.显然这是不希望的.因此，在遵循该概念针对不同的场景/方面进行单独的测试时，请使自己熟悉诸如参数化测试"或测试助手方法之类的概念.

Update: Having four tests instead of one can mean some code duplication. Obviously this is undesired. Therefore, when following the concept to have separate tests for separate scenarios / aspects, make yourself familiar with concepts like "parameterized tests", or, test helper methods.

这篇关于如何为同一方法命名不同的测试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！