这是一个糟糕的设计吗？

Question

我正在尝试行为驱动开发，但我发现自己在编写设计时再次猜测我的设计。 这是我的第一个绿地项目，可能只是我缺乏经验。 无论如何，这是我正在编写的类的简单规范。 它是用 BDD 风格的 NUnit 编写的，而不是使用专用的行为驱动框架。 这是因为该项目以 .NET 2.0 为目标，而所有 BDD 框架似乎都已接受 .NET 3.5。

[TestFixture]
public class WhenUserAddsAccount
{
    private DynamicMock _mockMainView;
    private IMainView _mainView;

    private DynamicMock _mockAccountService;
    private IAccountService _accountService;

    private DynamicMock _mockAccount;
    private IAccount _account;

    [SetUp]
    public void Setup()
    {
        _mockMainView = new DynamicMock(typeof(IMainView));
        _mainView = (IMainView) _mockMainView.MockInstance;

        _mockAccountService = new DynamicMock(typeof(IAccountService));
        _accountService = (IAccountService) _mockAccountService.MockInstance;

        _mockAccount = new DynamicMock(typeof(IAccount));
        _account = (IAccount)_mockAccount.MockInstance;
    }

    [Test]
    public void ShouldCreateNewAccount()
    {
        _mockAccountService.ExpectAndReturn("Create", _account);
        MainPresenter mainPresenter = new MainPresenter(_mainView, _accountService);
        mainPresenter.AddAccount();
        _mockAccountService.Verify();
    }
}

MainPresenter 使用的接口还没有任何真正的实现。 AccountService 将负责创建新帐户。 IAccount 可以有多个实现定义为单独的插件。 在运行时，如果有多个帐户，系统将提示用户选择要创建的帐户类型。 否则，AccountService 将简单地创建一个帐户。

让我不安的事情之一是编写一个规范/测试需要多少次模拟。 这只是使用 BDD 的副作用还是我处理这件事的方式错误？

[更新]

这是 MainPresenter.AddAccount 的当前实现

    public void AddAccount()
    {
        IAccount account;
        if (AccountService.AccountTypes.Count == 1)
        {
            account = AccountService.Create();
        }
        _view.Accounts.Add(account);
    }

欢迎任何提示、建议或替代方案。

Answer 1

当进行自上而下的开发时，发现自己使用大量模拟是很常见的。 你需要的部分不存在，所以你自然需要嘲笑它们。 话虽如此，这确实感觉像是一个验收水平测试。 根据我的经验，BDD 或上下文/规范在单元测试级别开始变得有点奇怪。 在单元测试级别，我可能会做更多类似的事情...

when_adding_an_account
   should_use_account_service_to_create_new_account
   should_update_screen_with_new_account_details

您可能需要重新考虑 IAccount 接口的使用。 我个人坚持
通过域实体保留服务接口。 但这更多的是个人喜好。

其他一些小建议...

• 您可能需要考虑使用模拟框架，例如 Rhino Mocks（或 Moq），它允许您避免在断言中使用字符串。

  _mockAccountService.Expect(mock => mock.Create())
     .Return(_account);

• 如果您正在使用 BDD 风格，我见过的一种常见模式是使用链式类进行测试设置。 在您的示例中...

public class MainPresenterSpec 
{
    // Protected variables for Mocks 

    [SetUp]
    public void Setup()
    {
       // Setup Mocks
    }

}

[TestFixture]
public class WhenUserAddsAccount : MainPresenterSpec
{
    [Test]
    public void ShouldCreateNewAccount()
    {
    }
}

• 我还建议更改您的代码以使用保护子句..

     public void AddAccount()
     {
        if (AccountService.AccountTypes.Count != 1)
        {
            // Do whatever you want here.  throw a message?
        return;
        }

    IAccount account = AccountService.Create();

        _view.Accounts.Add(account);
     }

Answer 2

如果您使用自动模拟容器，例如 RhinoAutoMocker（结构图）。 您使用自动模拟容器创建被测试的类，并向其询问测试所需的依赖项。 容器可能需要在构造函数中注入 20 个东西，但如果您只需要测试其中一个，则只需请求该一个即可。

using StructureMap.AutoMocking;

namespace Foo.Business.UnitTests
{
    public class MainPresenterTests
    {
        public class When_asked_to_add_an_account
        {
            private IAccountService _accountService;
            private IAccount _account;
            private MainPresenter _mainPresenter;

            [SetUp]
            public void BeforeEachTest()
            {
                var mocker = new RhinoAutoMocker<MainPresenter>();
                _mainPresenter = mocker.ClassUnderTest;
                _accountService = mocker.Get<IAccountService>();
                _account = MockRepository.GenerateStub<IAccount>();
            }

            [TearDown]
            public void AfterEachTest()
            {
                _accountService.VerifyAllExpectations();
            }

            [Test]
            public void Should_use_the_AccountService_to_create_an_account()
            {
                _accountService.Expect(x => x.Create()).Return(_account);
                _mainPresenter.AddAccount();
            }
        }
    }
}

从结构上讲，我更喜欢在单词之间使用下划线而不是 RunningThemAllTogether，因为我发现这样更容易扫描。 我还创建了一个以被测类命名的外部类和多个以被测方法命名的内部类。 然后，测试方法允许您指定被测方法的行为。 当在 NUnit 中运行时，这会给你一个如下的上下文：

Foo.Business.UnitTests.MainPresenterTest
  When_asked_to_add_an_account
    Should_use_the_AccountService_to_create_an_account
    Should_add_the_Account_to_the_View

Answer 3

对于具有应该返还帐户的服务的演示者来说，这似乎是正确的模拟次数。

不过，这看起来更像是验收测试而不是单元测试 - 也许如果您降低断言复杂性，您会发现更少的关注点被嘲笑。

Answer 4

是的，你的设计有缺陷。 您正在使用模拟：）

更严重的是，我同意之前的海报，他建议您的设计应该分层，以便可以单独测试每一层。 我认为测试代码应该改变实际的生产代码在原则上是错误的——除非这可以自动且透明地完成，就像编译代码以进行调试或发布一样。

这就像海森堡不确定性原理 - 一旦你有了模拟，你的代码就会发生很大的变化，这会成为维护的难题，而且模拟本身有可能引入或掩盖错误。

如果您有干净的接口，那么我对实现一个模拟（或模拟）另一个模块的未实现接口的简单接口没有异议。 这种模拟可以像模拟一样用于单元测试等。

Answer 5

您可能想要使用 MockContainers 为了摆脱所有的模拟管理，同时创建演示者。 它大大简化了单元测试。

Answer 6

这没关系，但我希望那里有一个 IoC 自动模拟容器。 代码暗示测试编写者手动（明确）在测试中的模拟对象和真实对象之间切换，但事实不应该是这样，因为如果我们谈论的是单元测试（单元只是一个类），自动模拟所有其他类并使用模拟会更简单。

我想说的是，如果您有一个同时使用 mainView 和 mockMainView 的测试类，那么您就没有严格意义上的单元测试这个词——更像是集成测试。

Answer 7

我认为，如果您发现自己需要模拟，那么您的设计就是不正确的。

组件应该分层。 您单独构建和测试组件 A。 然后构建并测试 B+A。 一旦满意，您就构建 C 层并测试 C+B+A。

在您的情况下，您不需要“_mockAccountService”。 如果你的真实AccountService已经过测试，那么就使用它吧。 这样你就知道任何错误都在 MainPresentor 中，而不是在模拟本身中。

如果您的真实 AccountService 尚未经过测试，请停止。 返回并执行您需要的操作以确保其正常工作。 当你真正可以依赖它时，你就不再需要模拟了。