当您编写代码来满足为接口编写的一些测试时,您可能会将注意力从构建可维护代码,从简洁设计和声音架构转移.
我有一个问题,没有测试驱动.有什么想法吗？
如果做得好,测试驱动开发是您的设计工具.
我希望您原谅我链接到my own blog entry,wherein I discuss the pitfalls of Test Driven Development that went wrong只是因为开发人员将他们的测试仅仅视为测试.
在之前的项目中,开发人员使用了一种高度破坏性的单例模式,在整个项目中强制执行依赖项,这在需求发生变化时突破了整个过程：
TDD was treated as a task,when it
should have been treated as an an
approach. […]There was a failure to recognize
that TDD is not about tests,it’s
about design. The rampant case of
singleton abuse in the unit tests made
this obvIoUs: instead of the test
writers thinking “WTF are these
singleton = value; statements doing in
my tests?”,the test writers just
propagated the singleton into the
tests. 330 times.The unfortunate consequence is that
the build server-enforced testing was
made to pass,whatever it took.
正确的测试驱动开发应该让开发人员高度意识到紧耦合,违反DRY(不要重复自己),违反SRP(单一责任原则)等设计缺陷.
如果为了通过测试而为测试编写传递代码,那么你已经失败了：你应该努力将测试写成让你问的路标：为什么这样做？为什么我不能在不依赖其他代码的情况下测试这段代码？为什么我不能重用这段代码？为什么这个代码在单独使用时会破坏？
此外,如果您的设计真正干净,并且您的代码真正可维护,为什么为它编写测试并不简单？
