如domain-manager article 所示，我有兴趣创建一个集成测试工具，该工具可创建一个服务器和许多客户端，其中所有客户端都在单个进程中运行。但是一旦我实现了这个目标，我就会很想从单元测试框架（NUnit 或 VS Team 测试）中执行这样的集成和系统测试。
选择从单元测试框架中运行集成或系统测试有哪些优缺点？这是我自己的刺：
无论哪种方式，如果我的新集成测试代码没有放入单元测试框架中，您会推荐它放在哪里？换句话说，您会推荐哪些“集成测试”框架？
【问题讨论】：
标签： .net unit-testing integration-testing
我认为使用您已经熟悉的单元测试框架编写集成测试没有任何问题。由于这些是集成测试，因此有几件事可以将它们与您的单元测试区分开来。一是它们依赖于外部系统（即使您在代码中旋转其中一些系统），因此如果其中一个不可用，您的测试将失败。正如您已经指出的那样，另一个问题是集成测试需要更长的时间才能运行。
处理这些问题的方法是将构建脚本配置为不在 CI 构建期间运行集成测试，而是在计划构建期间运行它们（例如每晚构建）。开发人员能够按需手动运行集成测试也很重要，这样他们就可以在本地机器上验证没有任何测试被破坏，如果他们有，能够验证他们已经纠正了没有手动触发系统构建的问题。
根据您使用的测试框架，有不同的方法可以将单元测试与集成测试分开，以便您可以将构建配置为执行一个或两个。一种方法是将您的集成测试移动到一个单独的项目中，并且只在您的夜间构建期间在该项目中执行测试。另一种是使用Category attribute in NUnit 之类的东西将一些测试标记为集成测试。然后，您可以配置测试运行程序，为您不想执行集成测试的构建排除此类别中的测试。
【讨论】：
自动化测试的重点是帮助您进行测试。
您花时间编写一个测试。将来可以再次运行它是一件好事（它有助于确保您没有破坏任何东西）。
NUnit 是一个帮助您运行您想要运行的测试的系统。您将“更彻底的测试”与“人为的测试”混为一谈，这并不是一个坏人。
唯一的缺点是其中一些测试花费的时间太长；并且开发人员每次运行测试时都会被劝阻。到那时，对禁用测试进行分类（即选择性地和临时性地）是完全可以接受的。
我编写了专门用于在函数中记录错误的单元测试。没有立即修复它的需要since it's a one in a million chance that anyone will hit the bug（i've even been insulted for even testing the case)。但至少测试在那里 - 一直提醒大家该功能并不完美：
void TestDateToString_KnownBug_FailsOnPseudo();
当然我取消了那个测试，所以我没有看到它总是失败，但是单元测试的目的是让我的生活更轻松——而不是更痛苦。
【讨论】：
如果您考虑一下，大多数 unit 测试框架并不是特定于 unit 测试的。它们提供了运行任意代码位并验证其输出的工具。所有这些对于集成和系统测试来说都是必要的，即使还不够。
出于这个原因，我认为将“单元”测试框架用于非单元测试是完全合理的。
优点
缺点
【讨论】：