Приложение.архитектура с MVP и некоторыми конкретными сценариями модульного тестирования - PullRequest
Новая
       15

Приложение.архитектура с MVP и некоторыми конкретными сценариями модульного тестирования

0 голосов
/ 15 июня 2011

Это довольно специфический сценарий, но у меня проблемы с этим. В моем текущем проекте я впервые применяю все, что считаю хорошей практикой; таким образом, есть MVC / MVP для пользовательского интерфейса, DDD Onion Architecture в ядре, IoC, все в настоящее время тестируется на единицу / интеграцию. Но учтите следующее: когда в моем контроллере вспыхивает исключение, я хочу показать это пользователю в специальной форме, поэтому для модульного тестирования одним из способов будет, конечно, заставить мой контроллер другой просмотреть зависимость через конструктор (громоздкий для каждого контроллера), поэтому у меня есть глобальное хранилище экрана, где я могу позвонить:

ScreenRepository.Instance().ShowExceptionView(...)

Проблема в том, что вы не можете издеваться над синглетонами, но здесь я бы сказал, что они в каком-то смысле чистые. Чего мне не хватает, так это архитектурной концепции того, как бы вы организовали свой код для решения этой проблемы. Я могу еще раз перефразировать вопрос, чтобы прояснить: как провести модульное тестирование, а путем модульного тестирования как настроить архитектуру для этого? (Я твердо верю, что модульное тестирование приводит мою архитектуру к лучшему дизайну, поэтому, пожалуйста, никаких комментариев, таких как , не позволяйте тестам управлять вашим кодом или чем-то ...

Что теперь делает мой IoC: подключение контроллеров и представлений, репозитории и тому подобное, так что я могу сказать, что у меня есть центральное место для вызова IoC.Resolve<ISomeController>().

Редактировать: я не использую фальшивые фреймворки, которые могли бы ожидать вызова не-виртуальных неинтерфейсных методов ...

1 Ответ

1 голос
/ 15 июня 2011

В вашем конкретном случае, когда вы хотите внедрить зависимость для всех контроллеров, у меня будет BaseController, который будет иметь свойство типа IScreenRepository 

public class BaseController
{
  private IScreenRepository _screen = NullScreenRepository.Instance;
  public IScreenRepository Screen {get { return _screen; } set { _screen = value; } } 

}

Вы можете настроить IOC для внедрения зависимости свойств для всех ваших контроллеров. Также хорошо иметь NullScreenRepository, чтобы убедиться, что если ваша зависимость не внедрена, она не нарушит код, который создает экземпляр контроллера напрямую, а не из контейнера IOC (например, модульные тесты).

Таким образом, вы сможете использовать его во всех контроллерах, не беспокоясь о том, откуда он взялся. И вы можете издеваться над ним и полностью проверить свои контроллеры.

...