MsTest 生成的测试是实际的单元测试吗？
Visual Studio 2010 为我生成了一堆单元测试，这似乎很方便，但我怀疑它们是否是实际的单元测试。例如，它生成了一个名为 SaveTest 的测试，该测试执行以下代码：
User user = new User(); //I have to create a user
user.Save(); //This saves the user to the database.
//Assertions here....
我上面遇到的问题是，根据我的阅读，单元测试应该在隔离中测试事物，因此通过测试保存到数据库，这不是单元测试还是我错了，MsTest 是否弄错了？附带说明一下，User 是由 dbml 生成的，Save 会在我的 DataContext 上调用 SubmitChanges。
Visual Studio 2010 generated a bunch of unit tests for me which seems to be handy, but I question whether they are actual unit tests. For example, it generated a test it called SaveTest which executes the following code:
User user = new User(); //I have to create a user
user.Save(); //This saves the user to the database.
//Assertions here....
The problem I have above is that from what I have read, unit tests are supposed to test things in Isolation, so by testing Saving to the database, this is not a unit test or am I wrong and does MsTest get it wrong? As a side note, User is generated from by dbml and Save calles SubmitChanges on my DataContext.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您已经完成了隔离依赖项的必要工作，以便可以将具有副作用的调用路由到适当的模拟或存根依赖项以感知所需的效果，则自动生成的测试只是单元测试。这些工具不会完成构建代码以支持单元测试的工作；他们所能做的就是创建对各个公共接入点的呼叫。您还必须完成为每个测试安排依赖关系状态并断言您希望检查的条件的工作。
The auto-generated tests are only unit tests if you've already done the necessary work to isolate dependencies so that the calls with side effects can be routed to the appropriate mocked or stubbed dependencies for sensing the desired effects. The tools won't do the work of architecting your code to support unit testing; all they can do is create calls to the various public access points. You'll also still have to do the work of arranging your dependency states for each test and asserting the conditions you wish to check.
据我所知，MSTest 的智能不足以知道如何模拟它测试的行为。因此，如果您自己不模拟 User 的数据库依赖项，那么它就不是单元测试。
MSTest 和 NUnit 等“单元测试”框架仅提供运行一套编程测试的环境。您使用 [Test] 属性或类似属性装饰一个方法，它就会运行它。该测试可以是单元、集成、功能甚至验收级别，具体取决于测试所涵盖的代码范围。在我们的项目中，我们有一整套除了集成测试之外什么都没有的组件，它涵盖了功能的整个垂直部分，甚至是模型客户端验收测试用例。所有这些都是使用 NUnit 框架编写的。
你的开发环境不能阻止你在开发中犯错误；如果这是真的，就不需要质量检查了。
MSTest, AFAIK, will not be intelligent enough to know how to mock behavior that it tests. As such, if you don't mock the DB dependencies of User yourself, it's not a unit test.
"Unit-testing" frameworks like MSTest and NUnit provide little more than the environment in which to run a suite of programmatic tests. You decorate a method with the [Test] attribute or similar, and it'll run it. That test can be at the unit, integration, functional or even acceptance level, depending on the scope of code being covered by the test. In our project we have a whole assembly of nothing but integration tests, which cover whole vertical slices of functionality and even model client acceptance test cases. All of it is written using the NUnit framework.
Your development environment cannot prevent you from making mistakes in development; if that were true, there wouldn't be a need for QA.
所有这些单元测试框架实际上并不局限于进行单元测试。
您可以使用这些进行许多不同的测试类型，包括完整的系统测试和集中的集成测试。特别是当您添加测试代码/运行程序中使用的额外框架工具时。
如果您有一个非常薄的类，它的唯一责任是与外部系统集成，那么如果您围绕它创建测试，那么这些测试就是集中的集成测试，并且最好针对外部系统进行。只需确保将它们与单元测试分开，因为它们自然会变慢。
另一方面，如果对外部系统具有硬依赖性的类不仅仅是一个瘦类，那么问题就出在你的代码上;)。解决这个问题，本质上你的测试就不会出现这个问题。
All these unit test frameworks aren't really constrained to do unit tests.
You can do plenty of different test types with those, including full system tests and focused integration tests. Specially as you add extra frameworks tools used from your test code / runner.
If you have a very thin class that its only responsibility is integrating with an external system, then if you create tests around it those are focused integration tests and are best done hitting the external system. Just make sure to keep them separately from the unit tests since those will be naturally slower.
If on the other hand, the class that has the hard dependency to the external system isn't just a thin class, then the issue is with your code ;). Address it, and by nature your tests won't have that issue.