我对最近的博客“您应该测试什么”有很多React，有些人出于各种原因与我达成一致，另一些人则认为建议某些类可能不需要单元测试是完全危险的。 已经处理了什么测试，今天的博客涉及为什么要编写单元测试，而今天的示例代码是基于一个真实的故事：只有姓名，日期和事实已经改变。

一位客户最近请求紧急释放一些代码，以出于法律原因在其网站的相应页面上在屏幕上显示一条消息。

方案是，如果数据库中存在一条信息，则应在屏幕上显示该信息–这是一个非常简单的方案，可以通过几行简单的代码行就可以覆盖。 但是，在急于编写代码的过程中，开发人员没有编写任何单元测试，并且代码中包含一个直到补丁到达UAT才发现的错误。 您可能会问到错误是什么，这是我们在职业生涯中某个时候都已经完成的事情：添加不需要的分号';'。 到一行的结尾。

我将使用我以前的“测试技术”博客中使用的AddressService场景来演示代码的重新编写的特技双重版本，如下UML图所示：

在此演示中，功能已更改，但是逻辑和示例代码结构基本上保持不变。 在AddressService领域中 ，逻辑运行如下：

1. 从数据库获取地址。
2. 如果地址存在，则将其格式化并返回结果字符串。
3. 如果地址不存在，则返回null。
4. 如果格式化失败，请不要担心，并返回null。

重新编写的AddressService.findAddress（…）看起来像这样：

@Component
public class AddressService {private static final Logger logger = LoggerFactory.getLogger(AddressService.class);private AddressDao addressDao;public String findAddressText(int id) {logger.info("In Address Service with id: " + id);Address address = addressDao.findAddress(id);String formattedAddress = null;if (address != null);try {formattedAddress = address.format();} catch (AddressFormatException e) {// That's okay in this business case so ignore it}logger.info("Leaving Address Service with id: " + id);return formattedAddress;}@Autowired@Qualifier("addressDao")void setAddressDao(AddressDao addressDao) {this.addressDao = addressDao;}
}

您发现错误了吗？ 当我查看代码时，我没有……为了以防万一，我在下面注释了一个屏幕截图：

演示一个琐碎的错误（任何人都可以犯的一个简单错误）的目的是强调编写一些单元测试的重要性，因为单元测试可以发现问题并节省大量的时间和费用。 当然，每个组织都不同，但是发布上面的代码会导致以下事件序列：

• 该应用程序已部署到开发，测试和UAT。
• 测试团队检查了修改后的屏幕是否可以正常工作并通过了更改。
• 其他屏幕经过回归测试，发现不正确。 记录所有失败的屏幕。
• 提出了紧急的错误报告。
• 该报告通过各个管理级别。
• 该报告已传递给我（我想念午餐），以调查可能的问题。
• 该报告将发送给团队的其他三名成员进行调查（四双眼睛比一只更好）
• 找到并修复了有问题的分号。
• 该代码在dev中进行了重新测试，并签入到源代码管理中。
• 该应用程序已构建并部署到开发，测试和UAT。
• 测试团队检查修改后的屏幕是否可以正常工作并通过更改。
• 其他屏幕经过回归测试并通过。
• 紧急修复程序已通过。

上述一系列事件显然浪费了大量的工时，浪费了大量现金，不必要地增加了人们的压力水平，并破坏了我们在客户中的声誉： 所有这些都是编写单元测试的很好理由。

为了证明这一点，我编写了三个缺失的单元测试，只花了我额外的15分钟开发时间，与浪费的工时相比，这似乎是开发人员时间的一种很好的利用。

@RunWith(UnitilsJUnit4TestClassRunner.class)
public class WhyToTestAddressServiceTest {private AddressService instance;@Mockprivate AddressDao mockDao;@Mockprivate Address mockAddress;/*** @throws java.lang.Exception*/@Beforepublic void setUp() throws Exception {instance = new AddressService();instance.setAddressDao(mockDao);}/*** This test passes with the bug in the code* * Scenario: The Address object is found in the database and can return a* formatted address*/@Testpublic void testFindAddressText_Address_Found() throws AddressFormatException {final int id = 1;expect(mockDao.findAddress(id)).andReturn(mockAddress);expect(mockAddress.format()).andReturn("This is an address");replay();instance.findAddressText(id);verify();}/*** This test fails with the bug in the code* * Scenario: The Address Object is not found and the method returns null*/@Testpublic void testFindAddressText_Address_Not_Found() throws AddressFormatException {final int id = 1;expect(mockDao.findAddress(id)).andReturn(null);replay();instance.findAddressText(id);verify();}/*** This test passes with the bug in the code* * Scenario: The Address Object is found but the data is incomplete and so a* null is returned.*/@Testpublic void testFindAddressText_Address_Found_But_Cant_Format() throws AddressFormatException {final int id = 1;expect(mockDao.findAddress(id)).andReturn(mockAddress);expect(mockAddress.format()).andThrow(new AddressFormatException());replay();instance.findAddressText(id);verify();}
}

最后，冒着自鸣得意的风险，我不得不承认，尽管在这种情况下该错误不是我的，但在我学会编写单元测试之前，我过去曾将类似的错误发布到野外……
可从GitHub上获得源代码：

git：//github.com/roghughe/captaindebug.git

参考： 为什么要编写单元测试–来自JCG合作伙伴 Roger Hughes的测试技巧8 ，在Captain Debug's Blog中 。

相关文章 ：

• 测试技巧–不编写测试
• 端到端测试的滥用–测试技术2
• 您应该对什么进行单元测试？ –测试技术3
• 常规单元测试和存根–测​​试技术4
• 使用模拟的单元测试–测试技术5
• 为旧版代码创建存根-测试技术6
• 有关为旧版代码创建存根的更多信息–测试技术7
• 一些定义–测试技术9