我们目前正在使用单元测试来测试我们的项目。我们涵盖了大部分功能，但我认为我们的测试太脆弱了。
我想知道我们是否有任何特定的事情可以使单元测试更加灵活，因此它们不会因为错误的原因而中断。
有几个答案提到要小心嘲笑太多......那么嘲笑的正当理由是什么？我认为这可能是我们的主要问题之一，但是当你的应用程序主要是一个动态的，数据库驱动的网站时，你如何摆脱嘲弄？
答案 0 :(得分：17)
这是一个有点简单的答案，但表现出正确的心态：
尽可能 - 不要远离 - 确保你正在测试方法的“最终结果”而不关心它是如何到达那里的。需要注意的一件事是嘲笑 - 它非常有用，但很容易使你的测试变得脆弱。
答案 1 :(得分：5)
+1给Jon。好吧。
我发现以更多BDD风格构建我的测试有很多价值。那就是......拒绝每类固定装置的思维方式，而是选择每个上下文的装置。
我还发现RhinoMocks 3.5的AAA语法要好得多。
这些涵盖组织和清洁/可读测试。
为了让我的测试变得不那么脆弱，我开始重新开始嘲笑。模拟框架对于存根依赖关系至关重要，但模拟的越多，知道关于实现的测试越多。如果实现发生了变化（但行为没有改变）那么你的测试就不会破坏。
答案 2 :(得分：3)
同样+1给Jon。
在典型的工程方式中，答案始终是“它取决于”。
我建议你看一下“xUnit测试模式：重构测试代码”这本书。 （在这种情况下，x = {J，N}既可以覆盖Java和.NET世界，也不会明确地用于新的实际调用的xUnit框架。）
正如OO世界中出现的设计模式一样，TDD世界也出现了模式。值得一看。
答案 3 :(得分：2)
我发现当我的测试具有以下属性时，它们往往更脆弱
1）复杂地设置正确的状态以便测试实际的逻辑。 2）对嘲笑的期望很高。 3）测试代码的可读性差。 4）一般糟糕的系统设计。
为解决这些问题，我们尝试执行以下操作
1）更改系统设计以便简化测试设置，通常是通过应用SRP并在我们班级中查找责任泄漏。
2）使用模拟而没有明确期望模拟上执行的调用的数量或顺序。
3）将测试代码视为生产代码，执行代码，设计评审等。
答案 4 :(得分：0)
那么合理的原因是什么 嘲讽？我认为这可能是其中之一 我们的主要问题，但当你的 应用程序主要是动态的， 数据库驱动的网站，你怎么得到的 远离嘲笑？
模拟对象的原因包括