是否有管理单元和集成测试的 .net 框架？
我听说过单元测试的一个夸耀是，您可以在一分钟左右运行 2000 多个测试..因为唯一的限制是 CPU 速度和 RAM。然而，我喜欢在我的测试项目中包含外部依赖断言/测试（例如：应用程序登录的用户帐户是否对适当的表具有插入/更新/删除权限，以考虑数据库是否曾经迁移？）
是否有框架或受支持的方式来利用 MS 测试，以便您可以选择仅运行单元测试或仅运行集成测试，或单击按钮即可运行两者？
One of the boasts I've heard of unit testing is that you can run 2000+ tests in a minute or so.. because the only limit is cpu speed and ram. I, however like to include external dependency assertions/testing in my test projects (such as: does the user account the application logs on with have insert/update/delete permissions on the appropriate tables to account for if the db is ever migrated?)
Is there a framework or a supported way to utilize MS Tests in such a way that you can choose to run just the unit tests or just the integration tests, or both at the click of a button?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的。 :)
在 VS2008 中，当您创建测试项目时，Visual Studio 还会生成一个测试元数据文件，即 vsmdi 文件。一种解决方案可能只有一个元数据文件。此文件是解决方案中跨所有测试项目生成的所有测试的清单。打开元数据文件，将打开测试列表编辑器 - 用于编辑和执行文件的 GUI。
从测试列表编辑器中，您可以创建测试列表[例如UnitTestList、IntegrationTestList]，并将各个测试分配给特定的测试列表。默认情况下，测试列表编辑器会在“所有加载的测试”列表和“不在列表中的测试”列表中列出所有测试，以帮助分配测试。使用它们来查找测试组或将测试组分配到列表中。请记住，一项测试可能只属于一个列表。
有两种方法可以
一种选择适合开发人员的日常工作流程，另一种选择适合自动化构建流程。
我在上一个项目中设置了类似的东西。
这个功能非常有价值*。
理想情况下，每当我们修改代码库时，我们都希望运行每一个可以想象的测试。这为我们提供了对所做更改的最佳响应。
然而，在实践中，运行测试套件中的每个测试通常意味着在构建时间上增加几分钟或几小时的执行时间（取决于代码库的大小和构建环境）——这对于开发人员和持续集成 [CI] 环境来说成本高昂，两者都需要快速周转以提供相关响应。
指定显式测试列表的能力允许开发人员、CI 环境和最终构建环境有选择地定位功能位，而不会牺牲质量控制或影响整体生产力。
举个例子，我正在开发一个分布式应用程序。我们编写了自己的 Windows 服务来处理传入请求，并利用 Amazon 的 Web 服务进行存储。我们不想在每次构建时都运行我们的 Amazon 测试套件，因为
响应时间可以以数百毫秒为单位进行测量，在一批测试请求中，这很容易使我们 然而，我们想保留这些测试，因为我们需要一套来验证行为。如果作为一名开发人员，我对与 Amazon 的集成有疑问，我可以根据需要从我的开发环境中执行这些测试。当需要推广 QA 的最终版本时，Cruise Control 还可以执行这些测试，以确保另一个职能领域的人员不会无意中破坏 Amazon 集成。
我们将这些 Amazon 测试放入集成测试列表中，每个开发人员都可以使用该列表，并在调用 Cruise Control 来促进构建时在构建机器上执行。我们维护了另一个单元测试列表，该列表也可供每个开发人员使用并在每个构建上执行。由于所有这些都是内存中的[并且写得很好：]并且将在构建项目所需的时间内执行，因此它们不会影响单独的构建操作，并及时从 Cruise Control 提供出色的反馈。
*=有价值==重要。 “价值”是今天的关键词:)
Yes. :)
In VS2008, when you create a Test Project, Visual Studio will also generate a test metadata file, or vsmdi file. A solution may have only one metadata file. This file is a manifest of all tests generated within the solution across all Test Projects. Openning the metadata file, opens the Test List Editor - a Gui for editting and executing the file.
From the Test List Editor, you may create Test Lists [eg UnitTestList, IntegrationTestList], and assign individual tests to a specific Test List. By default, Test List Editor lists all tests in an "All Loaded Tests" list, and a "Tests Not in a List" list to help in assigning tests. Use these to find or assign groups of tests to lists. Remember, a test may belong to only one list.
There are two ways to invoke a Test List
One option is good for developers in their everyday work-flow, the other is good for automated build processes.
I setup something similar on the last project I worked on.
This feature is very valuable*.
Ideally, we would like to run every conceivable test whenever we modify our code base. This provides us the best response to our changes as we make them.
In practice however, running every test in a test suite often means adding execution times of minutes or hours to build times [depending on size of code base and build environment] - which is prohibitively expensive for a developer and Continuous Integration [CI] environment, both of which require rapid turnaround to provide relevant response.
The ability to specify explicit Test Lists allows the developer, CI environment, and Final build environment, to selectively target bits of funcionality without sacrificing quality control or impacting overall productivity.
Case in point, I was working on a distributed application. We wrote our own Windows Services to handle incoming requests, and leveraged Amazon's web services for storage. We did not want to run our suite of Amazon tests every build because
We wanted to retain these tests however, since we needed a suite to verify behaviour. If as a developer I had doubts about our integration with Amazon, I could execute these tests from my dev environment on an as needed basis. When it came time to promote a Final build for QA, Cruise Control could also execute these tests to ensure someone in another functional area did not inadvertently break Amazon integration.
We placed these Amazon tests into an Integration Test list, which was available to every developer and executed on the build machine when Cruise Control was invoked to promote a build. We maintained another Unit Test list which was also available to every developer and executed on every single build. Since all of these were In-Memory [and well written :] and would execute in about as long as it took to build the project, they did not impact individual build operations and provided excellent feedback from Cruise Control in a timely manner.
*=valuable == important. "value" is word of the day :)
NUnit
您可以在 中设置装置类别。
我有一个类别设置的集成测试。然后使用 NUnit GUI 您可以指定要运行的类别。
在 Visual Studio 中运行时，我使用 TestDriven.NET 来运行我的测试。我的测试项目中的测试按类型分开，因此这使得单独运行单元测试或集成测试变得更加容易。
NUnit
You can set fixtures up in categories.
I have my I integration tests set with a category. Then using the NUnit GUI you can specify which category to run.
When running in Visual Studio I use TestDriven.NET to run my tests. Tests are separated in my test projects by type, so this makes running unit tests or integration tests separately a lot easier.