当前位置：网站首页>什么时候应该编写单元测试？什么是TDD？

什么时候应该编写单元测试？什么是TDD？

2022-04-23 01:36:00 【魏波-】

一、传统方法与TDD方法

1、有人认为软件编码完成后编写单元测试（传统方法），流程如下：

缺点：编写完功能代码再写单元测试会导致单元测试“粒度”比较粗。对同样的功能代码，如果采用TDD方案，结果可能是用10个“小”的单测来覆盖，每个单测比较简单易懂，可读性可维护性都比较好，重构时单测的改动不大；如果用传统方法写的单测，往往是用1个“大”的单测来覆盖，这个单测逻辑就比较复杂，因为它要测的东西很多，可读性可维护性就比较差。

2、后来越来越多的人选择在软件编码之前写单元测试，这种方法成为测试优先或测试驱动开发（Test-Driven Development，TDD），流程如下：

说明：首先编写一个失败的测试，然后创建产品代码，并确保这个测试通过，接下来是重构代码或创建另一个会失败的测试。具体流程是先写少量功能代码，紧接着写单元测试，重复这两个过程，直到完成功能代码开发。这样做的结果是：基本上功能代码开发完，单元测试也差不多完成了。

（1）编写一个会失败的测试，以证明产品中代码或者功能的缺失。
编写测试的时候，要假设产品代码已经能工作了，这样测试的失败就说明产品代码中有缺陷。这个测试最初会编译失败，只有在添加了需要的代码后，编译才能通过，然后测试可以运行，但是会失败，因为还没有实现所需的功能。

（2）编写符合测试预期的产品代码，使测试通过。
（3）重构代码。
如果测试通过了，你就可以编写下一个单元测试或者进行重构，使代码可读性更强或者去除重复代码等。重构可以在编写多个测试后进行，也可以在每个测试后都进行。重构是一项重要的实践，他确保代码更易读，更好维护，同时还依然能通过之前编写的所有测试。