介绍

我喜欢自动化测试。 在一次极少的转移到op-ed ^1中，我想到了一些想法（阅读–意见）。

在开始如何最好地构成您的测试之前，我先简单问一下–测试的原因是什么？ 大致来说，我认为它们是：

1. 减少错误总数/提高产品稳定性
2. 确保软件按照规范运行
3. 以低成本，低影响实现上述目标。

我认为这可以归结为提供可以满足客户需求（功能），不执行客户不想要的功能（错误）的软件，并且不会造成太大的噪音（成本）。

选择系统

选择一个入门门槛低，人们渴望学习或已经知道的系统：

1. 在其中有价值的学习中，例如流行的行业标准，这些系统将得到更好的文档记录，更好的理解，更可靠，并且您的同事将更容易加入。
2. 我的意思是使用“范式”系统，即按原意使用它，而不是以异常的“范式”方式使用，这将使您的同事生活困难，并阻止采用。

您可以测试多个配置，其中某些测试仅适用于某些模块和配置吗？

它坚固吗？

1. 对测试对象的更改是否容易导致识别需要更改的测试？ 对基础实现的更改不应默默地破坏测试。
2. 避免使用完全动态的语言，编译时检查可防止出现印刷错误，并确定如果测试主题发生更改可能需要更改的测试。

考虑一下该系统对于开发人员和技术水平较低的人员是否都可以使用–您是否希望测试人员或QA能够编写测试？

曾几何时，我认为这毫无疑问：测试系统是否完全自动化？ 还是，每当您运营公司时，都会花您公司的钱吗？

写作测试

测试应该快速运行并快速编写：

1. 编写测试不应要求耗时的数据库，DLL或环境设置，而是要使这种性质的东西自动化。
2. 您不需要对定制系统的默契知识，没有人愿意沉迷于繁琐的手动设置。 这只是成本。
3. 问问自己–是否只需单击一个按钮即可进行其他人的测试？
4. 测试本身无需花费很长时间即可编写。

不要混淆测试的生产代码：

1. 不必担心编写最“有效的Java”测试代码或重复使用。 字段不必是“私有最终”。
2. 您无需在测试中强制执行编码标准。

测试行为，而不是方法（@Test使testMethodX无效吗？）：

1. 考虑一个基于BDD的系统。

考虑为接口编写测试，然后使用 参数化的运行程序，它将为每个实现运行相同的测试集。

测试失败应明确反馈给修复程序：

1. 捕获测试的输出，以便可以诊断故障。
2. 确保可以将失败的测试与其套件隔离运行，以便您专注于修复失败的测试。
3. 测试失败，修复错误的代码和重新运行测试之间的平均时间是多长时间？

测试支持和测试双打

文档支持代码：

1. 如果人们不知道测试双打或夹具，也不会重复使用。

对于JUnit，请考虑使用@Rules为测试提供mixin- esq组件。

首选假货：

1. 与存根，假人或模拟物相比，它们通常更具通用性和可重用性。
2. 与其他类型的双打相比，它们将使您对主题有更好的了解。
3. 他们通常可以与实现共享一个代码，从而进行测试。
4. 具有通过接口直接控制伪造品的能力，例如将组件置于普通API无法激发的错误模式，例如网络问题或硬件故障。

伪造第三方：

1. 在我的工作中，有大量与硬件相关的JNI / JNA代码。 通过仅伪造JNI方法，我们可以模拟各种事情，包括失败超时。 我通过伪造串行设备，伪造javax.comm.SerialPort并用模拟失败或其他错误的伪数据将其预加载来完成了类似的工作。
2. 这将与RESTful API等同样有效。

运行测试

现实点”：

1. 最好使用真实的代码而不是使用伪造品在具有代表性的设置上运行测试。
2. 尝试在容器外运行测试，以便在尽可能接近生产设置的情况下运行该软件。
3. 如果软件在特定的环境上运行，也可以在特定的环境下运行测试，即集成测试之前要进行部署（及其隐式测试），这反过来意味着部署应该是一个按钮。

然后使之可重复：

1. 一个人编写的测试可以很容易地被另一个人访问，即版本控制。
2. 无需繁琐，容易出错的工作即可将测试纳入版本控制和单按钮提交。
3. 它们可以在您的开发机以外的计算机上运行吗？
4. 如果不是自动化的话，就不会重复。

与构建系统集成：

1. 测试应该在开发机器上运行，并且CI服务器和QA中的每次运行都将使您对成品更有信心。
2. 它们应该在CI中运行，可能没有头，并同时执行相同的测试。 他们是否使用相同的硬编码目录？ 他们在同一端口上监听吗？

参考： 测试我们JCG伙伴亚历克斯·柯林斯在亚历克斯·柯林斯的博客博客。