java 在同一个测试用例或单独的测试用例中测试默认值和设置器

Test default value and setter in same test-case or separate test cases

提问by Ariod

Would you recommend doing any grouping of test cases within @Test methods, or have one @Test method per test scenario? For example, let's suppose that there are different ways to set the context in an application.

您会建议在 @Test 方法中对测试用例进行任何分组，还是每个测试场景都有一个 @Test 方法？例如，让我们假设在应用程序中有不同的设置上下文的方法。

Is the following idea acceptable?

下面的想法可以接受吗？

@Test
public void testContextSetting() {
    // Test default setting
    assert(...)

    // Test setting a context variable
    assert(...)

    ...
}

Or, would you rather suggest having it like this, having each method as atomic as possible:

或者，您是否更愿意建议像这样，让每个方法尽可能原子化：

@Test
public void textDefaultSetting() {
    // Test default setting
    assert(...)
}

@Test
public void testSettingContextVar() {
    // Test setting a context variable
    assert(...)

    ...
}

Any feedback would be appreciated.

对于任何反馈，我们都表示感谢。

采纳答案by M. Jessup

I prefer having one test case per method.

我更喜欢每种方法有一个测试用例。

First it is easier to see what cases are being tested if they are split into methods as opposed to looking for comments embedded in the code. Most IDEs will give you a summary of methods, so instead of saying "did I test edgecase XYZ?" and then hunting for a comment, or looking for the code that sets up that edgecase, you just look for the method named setupContextEdgeCaseXYZ().

首先，如果将它们拆分为方法，而不是查找嵌入代码中的注释，则更容易查看正在测试的案例。大多数 IDE 都会为您提供方法摘要，因此不要说“我测试了边缘情况 XYZ 吗？” 然后寻找评论，或寻找设置该边缘情况的代码，您只需寻找名为setupContextEdgeCaseXYZ().

A second reason is if you have multiple cases together one may fail and then the others never execute.

第二个原因是，如果您将多个案例放在一起，一个可能会失败，然后其他人永远不会执行。

 testDefaultCase()
 testInvalidInput()
 testEdgeCase1()
 testEdgeCase2()

With this structure it would be easier to determine that the input checking is bad and edge case 2 is handled improperly, but the others are OK (and you may find out that two failing cases are related and the problem is diagnosed faster).

使用这种结构，可以更容易地确定输入检查是错误的并且边缘情况 2 处理不当，但其他情况是可以的（并且您可能会发现两个失败的情况是相关的并且可以更快地诊断出问题）。

A third reason is you may accidentally leave values from a previous test set that invalidates a latter test in a inconspicuous way. A simple example:

第三个原因是您可能不小心留下了先前测试集中的值，从而以不显眼的方式使后面的测试无效。一个简单的例子：

@Test
public void testMyMethod() {
  //test default
  String test = Foo.bar(null);
  assertEquals("foo", test);

  //test case 1
  Foo.bar(aValue);
  //Oops forgot to set value above, this passes regardless of 
  //what the above call does
  assertEquals("foo", test);
}

By breaking cases apart you can avoid mistakes as above as that would turn into a compile error or warning.

通过将案例分开，您可以避免上述错误，因为这些错误会变成编译错误或警告。

回答by RMT

Best Practice is to have one test case per method. The method name describes the test that you are performing. It is easier to debug when your test fails when it is just one assert.

最佳实践是每个方法有一个测试用例。方法名称描述了您正在执行的测试。当您的测试只有一个断言时，当您的测试失败时更容易调试。

回答by Cris

Divide et impera :) so split in multiple small cases ...easier to fix in case of errors.

Divide et impera :) 所以拆分成多个小案例......更容易在出现错误时修复。

回答by Raedwald

You are confusing a testwith an assertion. Your test method with multiple asserts tests multiple things: default settingand setting a context variable. But a test method that tests one thing can also have multiple asserts.

您将测试与断言混淆了。带有多个asserts 的测试方法测试多种内容：默认设置和设置上下文变量。但是一个测试一件事的测试方法也可以有多个asserts。

A good pattern to use is for each test-case to have four phases:

一个好的使用模式是每个测试用例有四个阶段：

1. Setup: where you create the objects you need to perform the test, and if necessary alter those objects to put them in the required initial states.
2. Exercise: where you perform the operation that you are testing. This will be one method call, or a constructor call.
3. Verify: where you check that the objects under test are in the correct state(s), and check the value returned by the method you called in the exercisephase, if it returned a value. This is where you place your asserts. If you use this pattern, there is nothing wrong with placing multiple asserts in the verifyphase.
4. Teardown: where you destroy or close the objects you used to perform the test.

1. 设置：在此处创建执行测试所需的对象，并在必要时更改这些对象以将它们置于所需的初始状态。
2. 练习：执行您正在测试的操作的位置。这将是一个方法调用或构造函数调用。
3. 验证：您检查被测对象是否处于正确状态，并检查您在练习阶段调用的方法返回的值，如果它返回一个值。这是您放置asserts 的地方。如果使用这种模式，assert在验证阶段放置多个s没有任何问题。
4. 拆解：销毁或关闭用于执行测试的对象的位置。

That is the approach recommended in the book xUnit Test Patterns: Refactoring Test Codeby Gerard Meszaros.

这是Gerard Meszaros在xUnit 测试模式：重构测试代码一书中推荐的方法。

Contrast that pattern with what you have in your first example, in which it seems you would do this:

将该模式与您在第一个示例中的模式进行对比，在该示例中您似乎会这样做：

1. Initial setup
2. Exercise constructor
3. Verify default
4. Exercise to set a context variable
5. Verify setting of context variable
6. Teardown

1. 初始设置
2. 练习构造函数
3. 验证默认值
4. 练习设置上下文变量
5. 验证上下文变量的设置
6. 拆除

回答by Prem

Eclipse generates unit test per method which seems to be a reasonable approach. If the tested method is too complex to test it using one test method then You may consider re factoring it.

Eclipse 为每个方法生成单元测试，这似乎是一种合理的方法。如果测试的方法太复杂而无法使用一种测试方法对其进行测试，那么您可以考虑重新分解它。

But a much more better approach is to use TDD and write the tests upfront which will drive the rest of the design and implementation.

但更好的方法是使用 TDD 并预先编写测试，这将推动其余的设计和实现。

Personally I prefer to have one test per method along with the Java Code Coverage for Eclipse http://www.eclemma.org.

我个人更喜欢对每个方法进行一个测试以及 Eclipse http://www.eclemma.org的 Java 代码覆盖率。

The tool will tell You what You're actually testing.

该工具会告诉您您实际测试的内容。