如果我不太确定以下哪项测试是必要的还是多余的。考虑单元测试以下代码：
public class Locker {
public enum Type { FOO, BAR, FOOBAR };
private Locker() {}
public boolean shouldlock (int x) {
return x > 10;
}
public boolean lock (Type type, int x) {
switch (type) {
case FOO : return shouldlock(x);
case BAR : return shouldlock(x * 2);
}
return false;
}
}
测试用例1：测试shouldlock的true和false情况。-到目前为止毫无疑问。
Question 1:
测试用例2:lock(对于输入类型Foo)也要测试真用例和假用例，即两者都要测试？在其调用shouldlock的基础上，我们已经对这两种情况进行了测试。因此，它可能是多余的。但不太确定。
Question 2:
测试用例3：假设Question1的答案是真的，我们还需要测试Bar的真和假情况吗？
Question 3:
测试用例4：假设两个Question1 and Question2的答案都是真的。假设现在shouldlock被更改为私有(只是假设它)。测试中唯一的区别是我应该省略Test case 1吗？
Question 4:
测试用例5：是否需要检查唯一遗漏的枚举FOOBAR是否返回false？
Question 5:
假设问题4的答案是真的，那个么若明天的枚举包含100多个项目呢？如何进行这样的测试？
- 测试用例1-是，在边界条件(10，11)上测试true和false用例
-
测试用例2-模拟
shouldlock，并验证是否使用x调用它(可能使用测试的常数值)。使用类似Mockito的东西，并让它只在调用lock时调用真正的方法 -
测试用例3-与测试用例2相同，但验证
shouldlock是否称为wtihx * 2 -
测试用例4-您必须测试每种类型的边界用例：
FOO具有10和11，BAR具有5和6 -
测试用例5-是，只需要对
FOOBAR进行一次测试 - 您必须为新值编写测试。如果有更多的枚举值，但它们都进入默认情况，则不需要更多的单元测试。如果有额外的逻辑，应该编写单元测试(最好是在生产代码之前)来测试该逻辑
首先，这取决于您的代码必须处理哪些场景。从这个角度来看，您可以考虑以测试驱动开发(TDD)的方式来处理您的工作，在这种方式中，您首先编写应该涵盖所需功能的测试，然后编写使测试通过的代码
使用这种方法，您的问题没有一般有效的答案。这只取决于你需要什么以及你需要有多严格
其次，您可以考虑以下想法来处理单元测试：使单元测试的代码覆盖率尽可能高。我在这里主要考虑行覆盖范围和条件涵盖范围。这意味着在单元测试期间执行的代码应该由尽可能多的行组成，并且应该分别覆盖尽可能多个条件分支。
此外，使用这种方法，您可能希望尽可能减少冗余，也就是说，将行的执行次数保持在尽可能低的水平，但高于0(理想情况下为1)。在这种情况下，您的问题的答案是：
- 仅适用于一种情况，即
true或false - 为其中一个案例测试
BAR案例，但测试它(您想覆盖case BAR行 - 只要你同时涵盖
true和false两种情况，是的 - 是的，您还想覆盖
return false线路 - 代码覆盖率很重要，但当它没有回报时不要夸大。：)
为了这个问题，我知道这是一个人为的例子，所以我会笼统地回答。
您希望使用尽可能多的输入进行测试，以满足自己对代码工作的要求。当然，你可能会错过一些东西，但当你以后需要重新创建bug时，测试就会出现。
在shouldlock的情况下，我会用一组整数来测试代码的工作原理，比如一个非常低的负数，一个非常高的正数，0，以及你期望作为输入的更具代表性的数字。
就lock而言，你的问题表明你在考虑实施，我认为这是一个错误。你需要从客户的角度来思考这个方法。具体来说，不要说"我们还需要测试BAR吗？"相反，你只需要想一想客户端可以调用你的方法的合理方法，并进行相应的测试。这意味着使用所有的enum值。
就规模而言，我认为这个问题是没有意义的，因为用100个项目的enum进行测试的困难(尽管可能性不大)表明你应该改变实现，所以你的方法可能会改变。然后你的测试会反映出这一点。
至于将方法更改为private，则不必再对其进行测试。只有您的公共API需要测试。不过，您可能希望将断言添加到这些方法中。
底线是不要为100%的测试覆盖率而苦恼。回报是递减的，当发现一个错误时，你会有一个测试来复制并修复它