我觉得，当我经历这个过程，将更容易做应用程序完成后的测试，但如果我这样做，我会失去所有的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代码)非常好，应该指向正确的方向。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。