Question

我知道对此没有正确或错误的答案但是看看其他人如何构建他们的测试项目会非常有帮助吗？特别是对于多组装解决方案和管理不同的测试阶段，单元，集成，系统？

最重要的是，看看哪种结构适合在Continuous Integration Server（TeamCity）上运行测试版本会很有帮助？

最初我开始时：

Test (Namespace)
--Unit (Folder)
----ClassATests 
----ClassBTests
--Integration (Folder)
----ClassA+BTests 
----DBTests

Answer 1

我将单元测试和集成测试保存在单独的程序集（x.Tests.dll，y.IntegrationTests.dll）中，以便能够轻松找到在构建过程中运行的测试程序集。然后我可以找到* .Tests.dll并将其作为每日构建的一部分运行。集成测试在特定环境中手动运行，但仍可以从简单的构建脚本运行。

除此之外，TestClass-per-Class几乎是我遵循的规则，例外是小帮助程序类，它们都是从单个HelperTests夹具测试的。

Answer 2

我今天一直在考虑这件事。我继承了一个过去由多人维护和更新的测试项目，因此目前包含一个相当混乱的层次结构。

为了简化问题，我开始使用以下结构：

Tests (Namespace)
-- Infrastructure (Folder)
---- general utility classes (common to all tests)
---- any other config
-- ClassATests (Folder)
---- ClassATestBase (base class for setup of common mock objects etc.)
---- ClassATestMethods (helper methods for the ClassATests)
---- ClassATests (main test class)
-- ClassBTests (Folder)
etc.

到目前为止，我发现这种方法很有用，因为它意味着在任何给定测试期间运行的大多数代码都可以在同一个文件夹中找到。它还旨在避免一个巨大的TestMethods类的场景。

这可能不是最优雅的解决方案（对不起，没有双关语！），但它目前正在为我工作。不过，欢迎提出任何建议！

构建Visual Studio测试项目的最佳实践

2 个答案: