单元测试

测试驱动开发。

何时编写测试用例

TDD(Test-Driven Development)

1. 写一个测试

2. 运行这个测试，看到预期的失败

3. 编写尽可能少的业务代码，让测试通过

4. 重构代码

5. 不断重复以上过程

写单测会影响速度？

4MB

tdd.mp4

Open

实际操作

保持测试的整洁

测试必须随着生产代码的修改而修改，

测试代码越脏->就会越难修改->生产代码改动后维护测试代码耗时增长->开发周期变长->产品来问原因->开发者放弃了单测->开发无法确定对系统的修改会影响到哪一部分->故障率增加->开发者害怕大改动->生产代码开始变糟->重构？

结论：单元测试和生产代码一样重要

测试编写环节

1. 构造测试数据

2. 操作测试数据

3. 检验预期结果

每个测试一个断言

image-20211028180718659

每个测试都能快速归结于可快速理解的结论。

每个分支至少一个测试。

FIRST

快速

fast，因为要频繁的运行，所以要快，不然就懒得运行了。

独立

多个单元测试之间不要有依赖，避免引起一连串的错误。并可以按照任意顺序测试。

可重复

在任何环境中重复运行，不然总要去解释接口失败的原因。

自足验证

应该通过boolean值取判断输出，而不是看日志

及时

测试应该及时编写，不应该在编写生产代码之后编写测试代码。编写生产代码之后就会很容易遗漏或者难以测试。

遗留

具体效果需要真正实践后反馈。