如果您从事软件开发很长一段时间，那么您很容易理解单元测试的重要性。专家说，如果我们遵循这些编写junit单元测试的最佳实践，大多数bug都可以在单元测试阶段捕获，最终传递给质量团队。

“编写不好的单元测试非常容易，而这些测试对项目的附加值非常小，膨胀代码的成本会发生天文学般的变化。”

不过，糟糕的单元测试是现实，每个做代码评审的人都会偶尔（可能是有规律地）面对它。那么什么是坏的测试用例呢？如何识别坏的测试用例？

在这篇文章中，我试图找出8个这样的迹象，这将为您提供微妙的提示，即一个特定的测试用例可能不是一个好的测试用例，需要更新。

1） 测试通过，但不测试实际功能

相信我，我在以前的项目中见过这样的测试用例，它们似乎在代码中做了很多事情，但实际上它们什么也没做。他们向服务器发送请求，不管服务器响应什么，他们都在传递请求。恐怖！！

通过严格的代码评审，小心在代码库中生成这样的测试用例。一旦它们进入了您的代码库，它们将成为您的责任，您需要携带它们、构建它们并每次运行它们，但不会增加任何价值。

2） 测试无关的东西

这是坏测试用例的另一个标志。我见过开发人员检查多个不相关的东西，以便代码通过做一些事情，当然不一定是正确的事情。最好的方法是遵循单一责任原则，即一个单元测试用例应该只测试一件事情，仅此而已。

3） 在断言中测试多个事物

这个似乎和上面的符号相似，但事实并非如此。在前面的符号中，测试是测试不相关的东西，在这个符号中，单元测试测试正确的东西，但是在一个测试用例中测试很多这样的东西。这再次违反了单一责任原则。

好吧，请注意，我不鼓励每个测试用例使用单个断言。要测试单个实体，可能需要使用多个断言，根据需要进行测试。

例如，一个API在post body中获取一些参数，创建Employee对象并返回它作为响应。这个Employee对象可以有多个字段，比如名字、姓氏、地址等。编写一个测试用例只验证名字，然后另一个用于姓氏，另一个用于地址，这是代码的双重性，没有任何值。别这么做。

相反，为createemployee编写一个阳性测试用例，并验证该单元测试中的所有字段。否定的测试用例应该单独编写，在这种情况下只做一件事和一个断言。e、 g.一个名字空白的测试用例，一个名字无效的测试用例等等。所有这些否定的测试用例都可以使用一个断言进行验证，该断言期望响应中出现异常。

4） 使用反射测试访问受试者

这个真的很糟糕。试着把受试者换成他们需要的人。当被测试者发生代码重构时会发生什么。测试用例会爆炸。不要使用这个或允许使用任何一个。

5） 允许异常的测试

我得到了相当一部分这样的测试用例。在测试用例的末尾，他们默默地在小catch块中吞下异常。更糟糕的是，它们也不会发出失败的警报。异常是应用程序抛出的信号，用于传达发生了不好的事情，您必须对此进行调查。您不应该允许测试用例忽略这些信号。

每当您看到一个意外的异常时，请在没有失败的情况下使测试用例失败。

6） 取决于过度设置的测试

我不喜欢测试用例，它要求在开始测试实际的东西之前发生很多事情。这样的场景可能类似于：一个促进在线会议的应用程序。现在要测试特定类型的用户是否可以加入会议，下面是测试正在执行的步骤：

• 创建用户

• 设置用户权限

• 创建会议

• 设置会议属性

• 发布会议加入信息

• [测试]用户加入会议

• 通过/失败

现在在上面的场景中，有5个复杂的步骤必须在验证实际逻辑之前设置。对我来说，这不是一个好的测试用例。

一个正确的测试系统至少会有一个现有用户在系统中执行此活动。它将减少测试用例中至少两个步骤。如果你能找到合适的，他可以有一些已经创建好的会议来让这个测试用例真正集中。

另一种使其正确的方法是使用模拟对象。他们在那里就是为了这个目的。不是吗？？

7） 测试仅与开发人员计算机兼容

这一点并不常见，但在新生写作时，有时也很明显。它们使用依赖于系统的文件路径、环境变量或属性，而不是使用公共属性/路径等。小心他们。

8） 用文本负载填充日志文件

在快乐的日子里，他们似乎不会制造问题。但是，当下雨天来临时，他们把没有任何信息的不必要的文本放在日志文件中，使生活陷入地狱，并使试图在这些日志文件中找到隐藏内容的调试器陷入地狱。

测试不用于调试应用程序，因此不要将调试日志放在类语句中。一个Pass/Fail日志语句就足够了。相信我。

这些是我在过去几年学习的基础上的想法。我不指望你在以上几点上都同意我。但可能有其他的观点，这是非常酷的。但我想谈谈，你对这个话题的看法。