JUnit测试是否存在标准结构？通常每个测试应该有多少断言？

Question

我将用一个例子更好地解释这个问题：

假设我有一个函数，它接收一个X个整数的数组和一个额外的整数，该整数包含一个起始位置，它从该位置开始计算数组中10个数字的平均值，但忽略0值，并在数组从起始位置到结尾不包含10个或更多值时返回-1000000：

public double calculateAverage(ArrayList<Integer>, int startingPosition){
    //functionLogic
    return myAverage;
}

我对单元测试不是很熟悉，但我建议在这里进行以下测试：

• 使用一个20个整数列表和起始位置为5的测试（应返回从5到14的10个数字的平均值）
• 使用一个20个整数列表和起始位置为15的测试（应返回-1000000）
• 使用一个9个整数列表的测试（无论起始位置如何，应返回-1000000）
• 使用一个20个整数列表的测试，其中一半数字为0，起始位置为5（应返回5到14之间数字的平均值，不计算0）。
• 使用一个20个整数列表的测试，其中一半数字为0，起始位置为15（应返回-1000000）。

这些测试可能不足够，或者太多了，或者只是糟糕的测试，请随时提出任何改进意见，因为我相信大多数人对单元测试比我更了解。

我的问题：

我是否需要编写5个不同的JUnit测试函数？是编写只有5个断言的1个更好？还是将其分成2组和3组？

这里推荐的风格是什么？

感谢大家的耐心。

- Mayuso

Answer 1

相当广泛，但我认为“非正式”的共识是绝对限制测试中的断言数。

换句话说：您更喜欢多个小测试而不是少数巨大的测试。

推理：单元测试的核心思想是帮助您理解（然后修复）失败的根本原因。当您在一个测试方法中有多个断言或“测试”时，那么您要花费最初几分钟来理解该测试失败的确切位置。

将其与仅包含两三行（一些设置，然后是“执行”和验证/断言步骤）的测试进行比较。

此外：还有很多好的资料，例如javacodegeeks提供的材料。

- GhostCat

---

这只是一个例子，但实际上我现在有一个500行的类，目前有36个单元测试，而且我甚至没有覆盖100%的代码。这正常吗？ - Mayuso

听起来...很多。但这可能有很多原因；例如，您的核心类已经在做太多不同的事情（违反单一职责原则）。从这个意义上说：您可能会将该代码放在codereview.stackexchange.com上，看看其他人有什么想法。编写单元测试是编写任何类型的代码技能的技巧，只有当您进行审查时才能得到改进。审核得越多，学习和提高的机会就越多。 - GhostCat

刚刚看到了编辑和链接，谢谢分享，它给出了一些非常具体的建议，正好是我需要的。谢谢。 - Mayuso

这是一个作为“公共类”工作的类，因此在许多其他地方使用的每个函数都会作为静态函数放在这里。（包括10个数字的平均值、3个数字的平均值、检查X个数字是否是Y数字的倍数、检查字符串是否包含X字符等）许多简单的数学问题被用于许多其他类中。 - Mayuso

对于这种类型的数学问题，可能有更好的测试方法；也许 https://en.wikipedia.org/wiki/QuickCheck 这个工具可以提供帮助。换句话说：与其自己指定输入/输出，不如让运行时搜索会“破坏”测试的值。 - GhostCat

谢谢你的建议，我也会去看看。 - Mayuso

Answer 2

如果您不想编写很多测试方法，可以选择参数化测试。您只需拥有一个测试方法和一组输入及其相应的输出。

了解更多关于参数化测试的信息，请访问parameterized tests in action。

- Jobin