马丁的“清洁代码”中关于TDD的章节引起了我的想象。
然而。
这些天我主要是扩展或修复现有的大型应用程序
另一方面,TDD似乎只适用于从头开始编写。
谈论这些现有的大型应用:
1.他们没有写TDD(当然)
我不能改写它们
3.在时间框架内编写全面的TDD式测试是不可能的。
我还没有看到任何TDD“bootstrap”提到现有的大型monolite应用程序。
问题在于,这些应用程序的大多数类原则上只在应用程序内部工作 它们是不可分离的。它们不是通用的。只是为了解雇它们,至少需要整个应用程序的一半。一切都与一切联系在一起 那么,引导程序在哪里?
或者有TDD结果的替代技术 这是否适用于扩展未使用TDD开发的现有应用程序?
答案 0 :(得分:3)
引导程序是隔离您正在处理的区域,并添加要保留的行为和要添加的行为的测试。当然,困难的部分是使其成为可能,因为未经测试的代码往往会以一种难以隔离代码区域以使其可测试的方式纠缠在一起。
购买Working Effectively with Legacy Code,这可以提供有关如何完成您的目标的大量指导。
您可能还想查看此相关问题的答案Adding unit tests to legacy code。
答案 1 :(得分:2)
从小处开始。抓住一段可以合理地提取并制作成可测试类的代码,然后执行它。如果应用程序充斥着如此多的硬依赖关系和令人恐惧的意大利面条逻辑,你不可能重构而不必担心破坏某些东西,那么首先要做一堆集成测试,这样你就可以在开始搞乱之前/之后确认正确的行为用它。
答案 2 :(得分:0)
您现有的应用程序听起来好像有紧密耦合和大量技术债务。在这些情况下,您可以花费大量时间尝试编写全面的单元测试,其中可以更好地花时间进行重大重构,特别是促进松散耦合。
在其他情况下,使用Mocking框架将时间和精力投入到单元测试中可能是有益的,因为它有助于将应用程序分离以进行测试,从而可以测试单个组件。依赖注入技术可以与模拟结合使用,以帮助实现这一点。