单元测试编写
一位客户最近请求紧急释放一些代码,以出于法律原因在其网站的相应页面上在屏幕上显示一条消息。
方案是,如果数据库中存在一条信息,则应在屏幕上显示该信息–这是一个非常简单的方案,可以通过几行简单的代码行就可以覆盖。 但是,在急于编写代码的过程中,开发人员没有编写任何单元测试,并且代码中包含一个直到补丁到达UAT才发现的错误。 您可能会问到错误是什么,这是我们在职业生涯中某个时候都已经完成的事情:添加不需要的分号';'。 到一行的结尾。
我将使用我以前的“测试技术”博客中使用的AddressService场景来演示代码的重新编写的特技双重版本,如下UML图所示:
在此演示中,功能已更改,但是逻辑和示例代码结构基本上保持不变。 在AddressService领域中 ,逻辑运行如下:
- 从数据库获取地址。
- 如果地址存在,则将其格式化并返回结果字符串。
- 如果地址不存在,则返回null。
- 如果格式化失败,请不要担心,并返回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
翻译自: https://www.javacodegeeks.com/2011/12/why-you-should-write-unit-tests-testing.html
单元测试编写