C＃，nUnit和Rhino Mocks，如果适用的话。
我在尝试为一个复杂的函数编写测试时，我的TDD之旅继续进行。假设我正在编写一个表单，当保存表单时，必须同时保存表单中的依赖对象...例如表单问题的答案，如果有的话还包括附件以及“日志”条目（例如“blahblah更新了表单。”或“blahblah附加了一个文件。”）。此保存功能还会根据表单在保存功能期间更改的状态向各种人发送电子邮件。
这意味着为了完全测试表单的保存功能及其所有依赖项，我必须注入五到六个数据提供程序来测试这个函数，并确保一切都按正确的方式和顺序触发。当编写多个链接的构造函数以插入模拟提供程序时，这很麻烦。我认为我错过了一些东西，无论是重构的方式还是简单地设置模拟数据提供程序的更好方法。
我应该进一步研究重构方法，以查看如何简化此函数吗？观察者模式听起来怎么样，这样依赖对象就可以检测到父表单何时被保存并处理自己？我知道人们说要拆分函数以进行测试...这意味着我测试每个依赖对象的单独保存函数，但不测试表单本身的保存函数，因为它规定了每个对象应该如何首先保存自己？
首先，如果你正在遵循TDD，则不要将测试包装在一个复杂的函数周围。相反，你需要将函数与测试交织在一起，几乎同时编写两者，但测试略领先于函数。查看TDD的三个法则。
当你遵循这三条法则，并勤于重构时，你永远不会得到“一个复杂的函数”。相反，你会得到许多经过测试的简单函数。
现在，回到你的问题。如果你已经有了“一个复杂的函数”，并且想要在它周围包装测试，则应执行以下操作：
如果在所有这些操作之后，DI仍然很麻烦，那么考虑注入一个包含所有数据源引用的单个对象。注入一个东西总比注入多个东西容易。
使用AutoMocking容器。RhinoMocks已经有一个写好的。
想象一下你有一个通过构造函数注入了很多依赖项的类。以下是使用RhinoMocks设置它的样子，不使用AutoMocking容器：
private MockRepository _mocks;
private BroadcastListViewPresenter _presenter;
private IBroadcastListView _view;
private IAddNewBroadcastEventBroker _addNewBroadcastEventBroker;
private IBroadcastService _broadcastService;
private IChannelService _channelService;
private IDeviceService _deviceService;
private IDialogFactory _dialogFactory;
private IMessageBoxService _messageBoxService;
private ITouchScreenService _touchScreenService;
private IDeviceBroadcastFactory _deviceBroadcastFactory;
private IFileBroadcastFactory _fileBroadcastFactory;
private IBroadcastServiceCallback _broadcastServiceCallback;
private IChannelServiceCallback _channelServiceCallback;
[SetUp]
public void SetUp()
{
_mocks = new MockRepository();
_view = _mocks.DynamicMock<IBroadcastListView>();
_addNewBroadcastEventBroker = _mocks.DynamicMock<IAddNewBroadcastEventBroker>();
_broadcastService = _mocks.DynamicMock<IBroadcastService>();
_channelService = _mocks.DynamicMock<IChannelService>();
_deviceService = _mocks.DynamicMock<IDeviceService>();
_dialogFactory = _mocks.DynamicMock<IDialogFactory>();
_messageBoxService = _mocks.DynamicMock<IMessageBoxService>();
_touchScreenService = _mocks.DynamicMock<ITouchScreenService>();
_deviceBroadcastFactory = _mocks.DynamicMock<IDeviceBroadcastFactory>();
_fileBroadcastFactory = _mocks.DynamicMock<IFileBroadcastFactory>();
_broadcastServiceCallback = _mocks.DynamicMock<IBroadcastServiceCallback>();
_channelServiceCallback = _mocks.DynamicMock<IChannelServiceCallback>();
_presenter = new BroadcastListViewPresenter(
_addNewBroadcastEventBroker,
_broadcastService,
_channelService,
_deviceService,
_dialogFactory,
_messageBoxService,
_touchScreenService,
_deviceBroadcastFactory,
_fileBroadcastFactory,
_broadcastServiceCallback,
_channelServiceCallback);
_presenter.View = _view;
}
private MockRepository _mocks;
private AutoMockingContainer _container;
private BroadcastListViewPresenter _presenter;
private IBroadcastListView _view;
[SetUp]
public void SetUp()
{
_mocks = new MockRepository();
_container = new AutoMockingContainer(_mocks);
_container.Initialize();
_view = _mocks.DynamicMock<IBroadcastListView>();
_presenter = _container.Create<BroadcastListViewPresenter>();
_presenter.View = _view;
}
更简单了，是吗？
AutoMocking容器会自动为构造函数中的每个依赖项创建模拟对象，并且您可以通过以下方式访问它们以进行测试：
using (_mocks.Record())
{
_container.Get<IChannelService>().Expect(cs => cs.ChannelIsBroadcasting(channel)).Return(false);
_container.Get<IBroadcastService>().Expect(bs => bs.Start(8));
}
希望这能有所帮助。我知道随着AutoMocking容器的出现，我的测试工作变得更加简单了。
你说得没错，这可能会很繁琐。
支持模拟方法的人会指出，代码本来就写得不正确。也就是说，你不应该在这个方法中构造依赖对象。相反，注入API应该有函数来创建适当的对象。
至于模拟六个不同的对象，那是真的。但是，如果你也正在对这些系统进行单元测试，那么这些对象应该已经有了可以使用的模拟基础设施。
最后，使用一个可以为你完成一些工作的模拟框架。
构造函数依赖注入并不是唯一的 DI 方式。如果你正在使用 C#，如果你的构造函数没有做任何重要的工作，你可以使用属性依赖注入。这在对象构造函数方面极大地简化了事情，但会增加函数的复杂性。在开始工作之前，你的函数必须检查任何依赖属性的空值，并在它们为空时抛出 InvalidOperation 异常。