实践
学习撰写良好的单元测试需要一定时间。一个困难的项目（更像是多个项目）并不奇怪。
已经推荐的xUnit Test Patterns书籍很好，我听说你正在阅读的那本书也不错。
至于一般性建议，这取决于测试中出现了哪些问题。如果它们经常出错，它们可能不是单元测试，而更像是集成测试。如果设置困难，则SUT（被测试系统）可能显示出过于复杂，并需要进一步模块化。清单还可以继续。
我遵循的一些建议是遵循AAA规则。
安排，执行和断言。每个测试都应该遵循这个公式。这使得测试易读，并且在需要维护时易于维护。
设计仍然很重要
我实践TDD，在编写任何代码之前，我会拿起白板涂鸦。虽然TDD允许您的代码逐步发展，但一些前期设计总是有益的。然后你至少有一个起点，从这里你的代码可以由你编写的测试驱动。
如果我正在执行特定的困难任务，我会制作一个原型。忘记TDD，忘记最佳实践，只是批量处理一些代码。显然，这不是生产代码，但它提供了一个起点。从这个原型开始，我再考虑真正的系统以及我需要什么测试。
查看Google Testing Blog-这是在开始TDD时对我自己的转折点。 Misko的文章（和网站-尤其是关于可测试代码的指南）非常好，并且应该指引您朝着正确的方向。
"当需求开始改变，我开始进行重构时，我发现我花费的时间在重写/修复单元测试上比写代码的时间还要多，事实上多得多。"
那么？这是一个问题吗？
你的需求改变了。这意味着你的设计必须改变。这意味着你的测试也必须改变。
"我花费的时间在重写/修复单元测试上比写代码的时间还要多，事实上多得多。"
这意味着你做得很对。需求、设计和测试的影响都在测试中，而你的应用程序并不需要太多的更改。
这就是它应该工作的方式。
回家高高兴兴。你已经做好了工作。
你是否广泛使用接口、依赖注入和模拟？
我发现，设计接口并使用像ninject这样的DI框架注入这些接口的实现，可以更轻松地模拟应用程序的部分内容，以便正确地测试各个组件。
这样，就可以更轻松地在一个区域进行更改，而不会对其他区域产生太大影响，或者如果确实需要传播更改，则只需更新接口，并逐个处理每个不同的区域。
你使用的是好的集成开发环境吗？几年前，当我第一次接触单元测试时，我也问过自己同样的问题。那时，我使用的是Emacs、find和grep的组合来进行重构。这很痛苦。
幸运的是，我的一个同事敲了我一下脑袋，并说服我尝试使用“现代工具”，在他的话中意味着Intellij IDEA。IDEA是我个人的首选，但Netbeans或Eclipse同样可以处理基本操作。这为我带来了难以言喻的生产力提升；特别是对于有大量测试的大型项目，效果更加显著。
一旦你选择了一个IDE，如果你仍然遇到问题，那么就该考虑DRY原则了。该原则旨在确保信息只保存在一个地方（常量、属性文件等），以便以后需要更改时最小化连锁反应。
