Rei*_* SE 13 testing tdd unit-testing legacy-code
情况:数百万行代码,超过一百个开发人员和频繁的缺陷.我们希望避免重复缺陷,我们希望改进代码设计(谁没有?).
测试驱动开发(第一个单元测试,然后是代码)听起来很理想:为每个函数编写一个测试用例.
但是,由于编写了如此多的代码,如何实现TDD?你从哪里开始 - 低级功能?
或者我们来不及启动TDD?
Car*_*ter 23
如果您从遗留代码开始,它不是真正的TDD - 但您的所有编码都可以是TDD.在解决新问题时,请为其编写测试.如果不能,因为遗留类太难以测试,那么就开始为它们编写测试,切掉位,并用测试覆盖这些位.
为避免重复缺陷:给出示例缺陷,编写一个演示它的测试.它可以是一个相对广泛的测试,只是模拟用户活动; 尚未进行单元测试.确保测试失败.做你的研究; 找出测试失败的原因.现在 - 这很重要 - 在修复bug之前,编写一个演示bug的单元测试.修复错误,现在你有两个测试,其中至少有一个快速,可以保护你免受回归.
| 归档时间: |
|
| 查看次数: |
4111 次 |
| 最近记录: |