unit-testing - MS Fakes 的 TDD

Question

我打算尝试 TDD，我正在为此研究合适的工具。在工作中，我们正在使用 MS Fakes，因此最好不要更改它并使用带有 TDD 的 MS Fakes。但我有一个严重的问题。在我看来，MS Fakes 旨在用于以下场景:编写代码 -> 为其编写单元测试。在 TDD 期间如何使用 MS Fakes 模拟某些接口(interface)？

例如我在一个文件中有以下代码(稍后会进行重构)

[TestClass]
public class MyTests
{
    [TestMethod]
    public void ShouldReturnSomeResultIfEmptyCollectionOfCustomersWasReturned()
    {
        // arrange
        ICustomerRepository customerRepository = null;
        var targetService = new MyTargetService(customerRepository);

        // act
        int result = targetService.MyMethod();

        // assert
        Assert.AreEqual(1, result);

    }
}

public class MyTargetService : IMyTargetService
{
    private readonly ICustomerRepository customerRepository;

    public MyTargetService(ICustomerRepository customerRepository)
    {
        this.customerRepository = customerRepository;
    }

    public int MyMethod()
    {
        if (customerRepository.GetCustomers().Any())
        {
            return 0;
        }

        return 1;
    }
}

public interface IMyTargetService
{
}

public interface ICustomerRepository
{
    Customer[] GetCustomers();
}

public class Customer
{
}

在我的 TDD 过程中，我将所有内容都放在一个文件中，然后重构它并转移到不同的程序集。但是我需要在这个地方模拟内联ICustomerRepository customerRepository = null; .例如，我可以使用 NSubstitute 轻松完成。但是，如果我使用 MS Fakes，我需要首先将此界面移动到另一个项目，从单元测试所在的项目中引用该项目，然后按“添加假程序集”。这看起来非常复杂的工作流程使得 TDD 不那么快速和高效。我希望在没有所有这些奇怪操作的情况下使用这样的代码:

ICustomerRepository customerRepository = new StubBase<ICustomerRepository>
                {
                    GetCustomers = () => Enumerable.Empty<Customer>().ToArray(),
                };

但是StubBase<>是抽象的。那么有没有办法用 MS Fakes 做这样的事情呢？

Answer 1

冒着引发口水战的风险，MS 套件中的大多数测试工具都是如此。简短回答:使用这些工具时，您应该就是否要使用它们做出明智的决定。如果您选择是，则您必须遵守 MS 对 TDD 或一般单元测试的定义 - 即使它看起来有悖常理。

• 编码的 UI 要求您在开始编写测试之前生成 UI map 。这要求 UI 完成后才能开始编写脚本测试。
• MSTest 强制您编写不能共享(创建成本高昂)状态的测试，即使它们属于同一个测试装置。这意味着必须一遍又一遍地运行昂贵的设置，以保持测试独立/并行友好。
• 通过 PEX，MS promise 通过自动生成测试用例来测试已编写代码的覆盖率。然而，它与 TDD 没有任何关系。

MS Fakes 似乎指示您需要右键单击包含您的接口(interface)的程序集并生成一个 Fakes 程序集。然后学习命名约定(这对我来说似乎有点奇怪)并将 lambda 表达式或委托(delegate)映射到可能由您的代码执行的每个接口(interface)成员。我担心生成的测试不可读/重构不友好。

对于您在抽象层(接口(interface))后面有依赖项的推荐情况，Rhino、Moq、NSubstitute 等常见的可疑对象可以正常工作而不会妨碍您。我发现 MS Fakes 的唯一地方是遗留代码或第三方代码，您无法访问源代码来解耦/注入(inject)依赖项。在这种情况下，MS Fakes 可能会有用。