Question

我刚加入的项目非常广泛地使用命令模式来处理对项目业务逻辑层的调用。

业务逻辑层构建为调用提供程序的静态处理程序。然后命令调用这些静态处理程序。

该团队希望提高测试覆盖率，我希望我们更多地转向真正的TDD，但使用静态处理程序意味着命令中存在硬编码依赖关系，并且无法将处理程序作为依赖项注入因此很难单独测试命令。

有没有人对策略有任何好的建议，让我们朝着更可测试的命令模式迈进，记住已经有很多命令在使用。

当在命令上调用execute时，将调用下面的处理方法。这将是被测试的方法。这是在命令类中使用静态处理程序的典型示例。

protected override bool Process()
{
    this.user = SecurityHandler.ActivateUser(this.activationGuid);
    bool success = this.user != null;

    if (!success)
    {
        this.AddStatusMessage(StatusMessageType.Error, "/Commands/Security/ActivateUserCommand/IncorrectLink", true);
    }

    return success;
}

Answer 1

Dependecy Injection（控制倒置）

静态依赖性是难闻的气味，通常可以使用DI / IoC来消除这种难闻的气味。找到您喜欢的任何DI / IoC框架并使用它。

Answer 2

静态方法/字段通常会受到可测试性的影响 - 因为它会导致测试不被隔离的风险。一个测试可以设置一些静态字段，改变test2的初始状态。

那说命令模式中没有任何东西需要静态处理程序..所以我认为这是一个自定义实现。我想看一些简短答案的示例代码。

没有简单的方法将静态部分移动到另一个类/对象中并将其传递给需要访问它的对象。这可能意味着向当前使用TypeName.StaticField调用的方法添加参数以获取数据。

更新（针对已发布的代码段）：我在这里看不到命令模式..无论如何都要获得测试方法。

SecurityHandler.ActivateUser是否有任何副作用？第二次调用它是否与第一次调用它有什么不同？如果没有（即它是纯粹的服务电话），那就不用担心了。
如果ActivateUser有一些副作用，那么你必须做一些工作。即将静态方法转换为实例方法，并将SecurityHandler的实例传递给包含类型的Process（）。您可以将其作为方法参数传递给Process（），也可以将ctor / property设置为包含类型。选择你认为合适的任何东西。

Answer 3

虽然这在设计模式方面没有帮助，但如果你现在想要增加测试，你总是可以使用像Typemock Isolator或Telerik JustMock那样的东西，它们允许你模拟静态类，同时您将代码转换为当前设计。（这些是商业产品）。

我自己也不会这样做，因为有一个危险你只是开始依赖它们而不是重复你的代码以使其可测试 - 我喜欢TDD /自动化测试的一个原因是它的力量你有松散耦合的代码并遵循一些好的设计原则，这样的工具可以带走它。

静态依赖退出策略

3 个答案: