Модульное тестирование, вызванное событиями

Question

Я использовал шаблон в течение некоторого времени.И мне интересно, правильно ли я поступаю.У меня есть класс контроллера, который прослушивает события и выполняет закрытый метод при возникновении события.Это выглядит примерно так:

public class MyController
{

    public MyController(IMyEventRaiser eventRaisingObject)
    {
        eventRaisingObject.MyEvent += HandleEvent;
    }

    private void HandleEvent(object sender, EventArgs args)
    {
        // SOME STUFF I WANT TO TEST!!
    }
}


public class EventRaisingClass : IMyEventRaiser
{
    public event EventHandler<EventArgs> MyEvent;
}

Единственный способ проверить код в MyController.HandleEvent - создать заглушку: IMyEventRaiser, которая вызывает код.

Я не уверен, что этот дизайн правильный.С одной стороны, я хочу сохранить метод HandleEvent закрытым, чтобы проиллюстрировать, что только событие может вызвать его.С другой стороны, этот закрытый метод содержит ключевую бизнес-логику, поэтому я чувствую, что он должен быть публичным или, по крайней мере, внутренним, что также облегчит юнит-тестирование.

Что ты много думаешь?

С уважением, Мортен

Answer 1

То, что у вас есть, звучит как (легкое) нарушение SRP . Ваш контроллер реагирует на события и содержит сложную логику, которая выполняется для определенного события. Что если бы ваш контроллер просто отправил необходимые данные на выделенный процессор, который действительно работал? Метод этого процессора обязательно будет общедоступным - и, следовательно, тестируемым! Разве не приятно, как TDD указывает на нарушения SRP?

Answer 2

Вы изучали Mocking Frameworks? «Moq» поддерживает создание события из фиктивного типа:

Mock<IMyEventRaiser> mock = new Mock<IMyEventRaiser>()
mock.Raise(e => e.MyEvent, EventArgs.Empty);