gtest 测试部分

这是三个系列文章中的第一篇。

1. 测试思路
2. 技巧
3. 工具和提示

心态

测试代码是需要学习的东西。 吸收如何做好需要花费时间。 这是一种应该始终练习和改进的技巧。

过去，开发人员没有进行测试，而是检查了他们的代码。 这是一个很好的技巧：

检查：代码执行编码人员打算执行的操作。 测试：代码可以执行客户所需的工作。 ＃ 敏捷 #tdd #bdd

—尼尔·基里克（@neil_killick） 2014年11月7日

今天，我们有许多工具和技术可以使用。 XUnit框架，模拟框架，UI自动化，TDD，XP…

但我相信测试始于头脑。 心态。

为什么要测试

我真的应该回答吗？
测试是您的代码工具和质量保证。 测试说明了代码的故事。 他们证明某事有效。 如果出现问题，他们会立即提供反馈。 正确使用测试可以使您更加高效。 您调试的次数更少，并且可能的bug更少，因此您有更多的时间进行实际工作。 您的设计将更好（以后会更多）并易于维护。 您有信心更改代码（重构）。 稍后会更多。 随着您对代码更加自信， 它可以减轻压力 。

测试什么

我什么都说。 也许您会跳过系统的最底层。 读取/写入文件系统或DB或传达某些外部服务的部分。 但是，即使这些零件也可以测试。 他们应该。 在下面的博客中，我将介绍一些技巧。

测试最小的东西。 例如，如果您有一个DTO，并且您决定将某个字段初始化为某个值，那么进行一个仅实例化该类然后验证（确认）期望值的测试（是的，我知道，某些部分确实无法测试，但应保持最小）。

建议零售价

单一责任原则。 这就是我喜欢提到测试需要检查一件事的观点。 如果是单元测试，则应该测试方法/类的一种行为。 应该在不同的测试中测试不同的行为。 如果是更高级别的测试（集成，功能，UI），则适用相同的原则。 测试系统的一个流程。 测试点击。 测试将元素正确添加到数据库，但不能在同一测试中删除。

隔离

隔离测试可以帮助我们准确了解出了什么问题。 开发独立的测试有助于我们一次专注于一个问题。

隔离的一方面与SRP有关。 测试某些东西时，请将测试的代码与其他部分（依赖项）隔离开。 这样，你测试代码的那一部分。 如果测试失败，那么您知道是。 如果您在测试中有很多依赖关系，那么很难弄清实际的失败原因是什么。

但是隔离也意味着其他事情。 这意味着没有测试会干扰其他测试。 这意味着测试的运行顺序无关紧要。 对于单元测试，这意味着您不需要运行数据库（或与此相关的Internet连接）。 这意味着您可以同时运行测试，而不会互相干扰（maven完全可以做到这一点）。 如果您做不到（例如：数据库问题），那么您的测试就不会孤立。

测试气味

如果测试难以理解/难以维护，请不要生气！ 说：

亲爱的测试人员，非常感谢您帮助我改善代码

如果为测试设置环境太复杂，则可能是所测试的单元具有过多的依赖性。

如果在运行被测方法之后，您需要验证许多方面（验证，断言等），则该方法可能做得太多。 该测试可以成为您改善代码的最好朋友 。

通常，真正复杂的测试代码意味着结构化的生产代码更少。 我通常会看到复杂的测试与不遵循SRP或任何其他DOLID原理的代码之间的相关性。

可测试的代码

这是我的最爱之一。 每当我进行代码审查时，我都会问对方：“您将如何对其进行测试？”，“您如何知道它的工作原理？” 每当我编写代码时，我都会问自己同样的问题。 “我如何测试这段代码？”

以我的经验，始终思考如何创建可测试的代码会产生更好的设计。 该代码“神奇地”具有更多的模式，更少的重复，更好的OOD且行为稳定 。

强迫自己不断测试代码，会让您思考。 它有助于将大而复杂的问题分解为许多（或很少）较小，更琐碎的问题。

如果您的代码是可测试的且经过测试，则您对此更有信心。 对行为充满信心，并有信心改变它。 重构它。

重构

这个项目可以是为什么的一部分。 它也可以是技术的一部分。 但是我决定特别注意它。 重构是TDD周期的一部分（但不仅如此）。 当您进行测试时，您可以确信进行重构。 我认为您在开发时需要“考虑重构”。 类似于“思考如何生成可测试的代码”。 在考虑重构时 ，会进行测试。

重构也是一种心态。 问问自己：“我产生的代码是否足够干净？ 我可以改善吗？” （顺便说一句，知道什么时候停止…）

这是有关测试的一系列文章中的第一篇。 以下文章将介绍一些测试技术和方法。

翻译自: https://www.javacodegeeks.com/2014/11/its-all-about-tests-part-1.html

gtest 测试部分