我们经常很难找到给定生产代码类的单元测试，即使使用诸如测试程序集名称为生产代码程序集名称+“.Tests”以及测试程序集中一致的命名空间和文件夹等约定。
当类由于重构而被重命名或移动时，就会出现这个问题。有没有一种解决方案可以自动执行这些约定，或者有没有一种更好的方法可以使给定代码类的单元测试更容易被发现？
当然，我们可以在IDE中使用“查找引用”功能，但我们通常只加载包含当前正在处理的代码的程序集，以提高性能。
我们经常很难找到给定生产代码类的单元测试，即使使用诸如测试程序集名称为生产代码程序集名称+“.Tests”以及测试程序集中一致的命名空间和文件夹等约定。
当类由于重构而被重命名或移动时，就会出现这个问题。有没有一种解决方案可以自动执行这些约定，或者有没有一种更好的方法可以使给定代码类的单元测试更容易被发现？
当然，我们可以在IDE中使用“查找引用”功能，但我们通常只加载包含当前正在处理的代码的程序集，以提高性能。
1条答案
按热度按时间f0brbegy1#
一个可能的解决方案是为测试编写测试，😉Roslyn API使分析C#文件的结构变得非常简单。因此，测试可能看起来像这样：
1.用Roslyn加载整个解决方案。
1.迭代所有不以
Fixture、Test等为结尾的类。（无论您的测试后缀是什么）。1.对于#2的每个元素，检查是否存在具有后缀（测试类）的对应元素。
个人观点
但根据代码的大小和结构，我认为这是一种反模式。为什么？因为如果我们不区分 * 测试代码 * 和 * 生产代码 ，我们会这样说： 嗯，每当我必须更改类A时，我也必须更改类B 。
这是高耦合，我们通常希望避免（尽管可能有例外）。
Imho * 测试代码 * 是代码库的一等公民，因此， 测试代码 * 和 * 生产代码 * 之间没有区别-只有 * 代码 *。而代码需要一个特定的架构来保持其可维护性，即即去耦等。
因此，我投票支持根据特性而不是类来命名测试类，并根据行为而不是类方法来命名测试方法。
如果您对这个主题感兴趣，我可以推荐Dennis Doomen's blog The Continous Improver，特别是以下两篇文章：