我最近完成了一个使用TDD的项目，我发现这个过程有点噩梦。我喜欢写测试第一，看我的代码增长，但一旦需求开始改变，我开始做重构我发现，我花了更多的时间重写/修复单元测试比我写代码，事实上更多的时间。
我觉得，当我经历这个过程，将更容易做应用程序完成后的测试，但如果我这样做，我会失去所有的TDD的好处。
那么有没有任何点击/提示编写可维护的TDD代码？我目前正在阅读Roy Osherove的The Art Of Unit Testing，还有其他资源可以帮助我吗？
谢谢
实践
需要一段时间来学习如何写出体面的单元测试。一个困难的项目(更像项目)是没有什么奇怪的。
xUnit Test Patterns的书推荐已经是好的，我听说过你正在读的书的好东西。
至于一般的建议，这取决于什么是艰难的测试。如果他们经常爆发，他们可能不是单元测试，更多的集成测试。如果它们难以设置，则SUT(被测系统)可能显示太复杂的迹象，并且将需要进一步的模块化。清单继续。
我住的一些建议是遵循AAA规则。
安排，行动和声明。每个测试应该遵循这个公式。这使得测试可读，并且如果它们确实中断，则易于维护。
设计仍然重要
我练习TDD，但在任何代码写之前，我抓住一个白板，涂鸦。虽然TDD允许你的代码进化，一些前面的设计总是一个好处。然后你至少有一个起点，从这里你的代码可以由你写的测试驱动。
如果我执行一个特别困难的任务，我做一个原型。忘记TDD，忘记最佳做法，只是抛弃一些代码。显然这不是生产代码，但它提供了一个起点。从这个原型，我然后考虑实际的系统，我需要什么测试。
查看Google Testing Blog – 这是我开始TDD时的转折点。 Misko的文章(和网站 – 特别是Guide to Testable代码)非常好，应该指向正确的方向。
