单元测试'结构'的方法？

Question

很抱歉写了这么长的文章……

在被介绍到一个棕地项目时，我对某些单元测试集和思考内容存有疑问。假设您有一个存储库类，包装了一个存储过程，并且在开发人员指南中，有一组特定的准则（规则），描述了应该如何构造该类。该类可能如下所示：

public class PersonRepository
{
public PersonCollection FindPersonsByNameAndCity(string personName, string cityName)
{
    using (new SomeProfiler("someKey"))
    {
        var sp = Ioc.Resolve<IPersonStoredProcedure>();

        sp.addNameArguement(personName);
        sp.addCityArguement(cityName);

        return sp.invoke();
    }
} }

现在，我当然会编写一些集成测试，测试 SP 是否可以被调用，以及行为是否符合预期。但是，我是否会编写断言以下内容的单元测试：

• 调用具有输入参数“someKey”的 SomeProfiler 的构造函数 调用
• PersonStoredProcedure 的构造函数
• 调用存储过程上的 addNameArgument 方法，并使用参数 personName
• 调用存储过程上的 addCityArgument 方法使用参数 cityName
• 在存储过程上调用 invoke 方法 -

如果是这样，除了行为之外，我可能会测试方法的整个结构。我最初的想法是，这太过分了。然而，就团队强制执行的编码实践而言，这些测试确保了统一且“正确”的结构，并且正确调用了下一层（从 DAL 到 DB、BLL 到 DAL 等）。

就我而言，这些类型的测试是针对应用程序的每一层执行的。

后续问题 - SomeProfiler 类的使用对我来说有点像一种约定 - 可以通过使用静态代码分析或单元测试 + 反射来创建约定样式的测试，而不是为此创建显式测试吗？

提前致谢。

Answer 1

我认为你最初的想法是正确的——这是一种矫枉过正的行为。尽管您可以使用反射来确保该类具有您期望的方法，但我不确定您是否想以这种方式测试它。

也许您应该使用一些工具（例如 FxCop/StyleCop 或 nDepend）来确保特定程序集/dll 中的所有类都具有这些属性，而不是进行单元测试。

话虽如此，我是“只编写你需要的代码”的信徒，为什么要测试一个方法是否存在，要么你在代码中的某个地方使用它，你可以测试特定的情况，要么你不测试 - 所以它是无关紧要。

Answer 2

单元测试应该关注行为，而不是实现。因此，编写测试来验证某些参数是否已设置或传入并不会给您的测试策略增加太多价值。

由于提供的示例似乎正在与您的数据库进行通信，因此它不能真正被视为“单元测试”，因为它必须与具有额外设置和先决条件的物理依赖项进行通信，例如环境的可用性、数据库模式、现有数据、存储过程等。您编写的任何测试实际上也在验证这些先决条件。

在目前的情况下，这些类型的测试的最佳选择是测试类提供的行为——调用存储库上的方法，然后验证结果是否符合您的预期。然而，您会突然意识到这里有一个隐藏的成本——数据库在测试运行之间维护状态，并且您需要额外的设置或拆卸逻辑来确保数据库处于众所周知的状态。

虽然我意识到问题的意图是关于测试“黑匣子”，但很明显，您的 API 中存在一些隐藏的魔力。我倾向于使用当前测试范围内的内存数据库来解决众所周知的状态问题，这将我与环境考虑隔离开来，并使我能够并行化我的集成测试。我敢打赌，在当前的设计下，不存在以编程方式引入数据库配置的“接缝”，因此您会“陷入困境”。根据我的经验，魔法会带来伤害。

然而，对现有设计的轻微改变解决了这个问题，“魔法”消失了：

public class PersonRepository : IPersonRepository
{
      private ConnectionManager _mgr;

      public PersonRepository(ConnectionManager mgr)
      {
         _mgr = mgr;
      }

      public PersonCollection FindPersonsByNameAndCity(string personName, string cityName)
      {
           using (var p = _mgr.CreateProfiler("somekey"))
           {
                 var sp = new PersonStoredProcedure(p);

                 sp.addArguement("name", personName);
                 sp.addArguement("city", cityName);

                 return sp.invoke();
           }
      }
}