我知道TDD上有很多东西,我也试图接受这种做法.但我想知道TDD你的错误修复是一个好主意吗?
我正在思考找到这个bug并缩小它的范围.编写单元测试以确保它现在可以传递它先前引起的任何问题.为其他易碎条件写更多单元测试.最后编写单元测试来测试集成测试,因为我们之前没有任何单元测试,因此每当我修复一个bug时,我总是担心我可能会意外破坏某些东西.
TDD也适合调试吗?
或者是否有其他方法或资源/书籍对此目的更有用?
正如我上面提到的,我更关注集成测试部分.我在LAMP/Axkit/Perl相关方法中寻找任何东西.
谢谢.
编写因错误而失败的测试.
修复代码中的错误.
重新运行测试.
重新运行所有测试.
所以 - 是的 - 非常如此.
当测试人员发现错误时,我通常会为它编写单元测试.当测试成功时,我知道错误是固定的,并且将来会再次被覆盖.
当您的系统中存在错误时,在TDD中编写一个可以发现错误的测试(即证明错误的红色测试)是一种很好的做法.当您必须修复错误时,测试最终应该变为绿色.如果它们足够接近,可能会发现任何其他错误.
关于调试,应该使用TDD来利用远离程序员的调试会话.您仍然可以调试,如果你不知道在哪里了一些bug是,但它更容易找出错误,如果你有一个回归测试套件以足够的粒度.
你必须记住尽管这TDD更多的是单元测试,而不是关于集成测试.没有什么错编写集成测试,因为他们是一个全面的检查,以确保您的应用程序或系统测试工作.
一本书,是关于与xUnit框架测试是xUnit的模式一书是足够一般以任何单元测试框架(甚至工作PerlUnit我猜)有趣的技巧食谱,你可以与xUnit框架做.
更新:有一个关于在Perl的单元测试章极端的Perl.