问测试驱动开发：.NET遵循测试驱动开发原则，模拟/不模拟？

EN

所以我想我应该使用一个模拟框架来模拟这个Repository类，但是这是正确的方法吗？

是的，这是一个完全正确的方法，因为你应该隔离测试你的类。即通过模拟所有依赖项。否则，您无法判断您的类是否失败或它的一些依赖项。

我最初写了我的测试并使其失败，现在我意识到我需要一个存储库并需要模拟它，所以我必须更改我的测试以迎合模拟对象。闻起来有点不对劲？

提取类、重组方法等都是一种重构。这里的测试可以帮助你进行重构，消除对变化的恐惧。如果实现发生变化，更改测试是完全正常的。我相信你不会认为你可以从第一次尝试就创建完美的代码，然后再也不会改变它？

如果这是可行的方法，那么我应该在什么时候创建实际的用户存储库？这需要自己的测试吗？

您将在应用程序中创建一个真正的存储库。您可以为这个存储库编写测试(例如，检查它是否正确地调用了底层数据访问提供程序，这应该是模拟的)。但这样的测试通常非常耗时且易碎。因此，最好编写一些验收测试，用真实的存储库测试整个应用程序。

，或者我应该忘记嘲笑任何东西吗？

恰恰相反--你应该使用mock来隔离测试类。如果模拟需要很多工作(数据访问、ui)，那么不要模拟这样的资源，而是在集成或验收测试中使用真实的对象。

您肯定会模拟出对数据库的依赖，然后在您的服务上断言，在您的模拟上调用预期的方法。我推荐您尝试遵循最佳实践，并鼓励您坚持这条道路。正如您现在已经意识到的，随着您的继续，您将开始向您编写的类添加新的依赖项。我强烈建议您在外部满足这些依赖关系，就像创建接口IUserRepository一样，这样您就可以模拟它，并将IUserRepository传递到服务的构造函数中。然后将其存储在一个实例变量中，并调用所需的方法(即_userRepository.StoreUser(user))。这样做的好处是，很容易从您的测试类中满足这些依赖关系，并且您可以将对象的实例化和生命周期管理作为一个单独的问题来考虑。

tl;dr:创建一个模拟！

我有两套测试库。一个是给UnitTests的，我在那里模仿一些东西。我只在那里测试单元。因此，如果我在服务中有一个AddUser方法，我将创建能够用该特定方法测试代码所需的所有模拟。这使我有可能测试一些我无法验证的代码路径。

另一个测试库是用于集成测试或功能测试，或者任何你想叫它的东西。这个是确保一个特定的用例。例如，从网页创建一个标签将会做我期望它做的事情。为此，我使用Visual studio 2012附带的sql服务器，每次测试后，我都会删除数据库并重新开始。

在我的例子中，我会说集成测试比单元测试重要得多。这是因为我的应用程序没有太多的逻辑，相反，它以不同的方式显示来自数据库的数据。