单元测试 – 编写源代码之前或之后的TDD和测试?

前端之家收集整理的这篇文章主要介绍了单元测试 – 编写源代码之前或之后的TDD和测试?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我已经看过许多关于为什么测试驱动开发是好的文章,它减少了开发时间等等.但在搜索了很多论坛后,我仍然没有得到TDD的具体优势.我并不是说测试是一件坏事,但我的观点是,如果我在编写源代码后编写单元测试而不是像TDD建议那样反之亦然.两个测试用例一旦完成就会像回归测试一样.在尝试在遗留代码中跟踪TDD时,我也遇到了很多问题.我想现在大多数代码都是遗留代码,我们必须在没有预先存在的测试的情况下修改代码.此外,TDD仅限于单元测试,甚至仅限于系统级和集成测试.我无法想象如何在不编写源代码的情况下进行集成测试.

解决方法

我不会说TDD会缩短开发时间.它甚至可能更长.但TDD导致“干净的代码有效”.软件在单元测试的同时增长,而不是一个接一个地增长,因此在编写后立即进行测试.这给开发者带来了信心以及对“他所处的位置”的一个好主意,因为他知道他到目前为止所完成的工作是“完成了”.

事后写单元测试也很难.作者“Working effectively with legacy code”(一个非常好的资源BTW)甚至说没有单元测试编写的代码确实是遗留代码.

Also is TDD limited to unit tests only
or even system level and integration
tests. I am just not able to imagine
how we can do integration tests
without writing source code.

TDD是一种开发技术,它不是要取代其他类型的测试.

然而,可以在要测试的代码存在之前编写集成测试.这允许询问自己如何测试将要生成代码.

猜你在找的设计模式相关文章