Упрощение тестирования благодаря соображениям проектирования при использовании внедрения зависимостей - PullRequest
1 голос
/ 23 марта 2010

Мы на несколько месяцев участвуем в экологичном проекте по переработке логического и бизнес-уровней нашего продукта. Используя MEF (внедрение зависимостей), мы достигли высокого уровня покрытия кода, и я считаю, что у нас довольно солидный продукт. Поскольку мы работали над более сложной логикой, мне стало все труднее проводить модульное тестирование.

Мы используем CompositionContainer для запроса типов, требуемых этими сложными алгоритмами. Моим модульным тестам иногда трудно следовать из-за длительного процесса настройки фиктивного объекта, который должен проходить, в точности, чтобы можно было проверить определенные обстоятельства. Мои модульные тесты часто занимают у меня больше времени, чем код, который я пытаюсь протестировать.

Я понимаю, что это проблема не только внедрения зависимостей, но и дизайна в целом. Виноват ли в моих слишком сложных тестах плохой дизайн метода или отсутствие состава? Я пробовал базовые классовые тесты, создавая часто используемые фиктивные объекты и стараясь максимально использовать контейнер, чтобы облегчить эту проблему, но мои тесты всегда оказываются достаточно сложными и трудными для отладки. Какие советы вы видели, чтобы такие тесты были краткими, удобочитаемыми и эффективными?

Ответы [ 2 ]

7 голосов
/ 23 марта 2010

Моя субъективная точка зрения:

  • MEF выглядит как действительно хороший плагин-фреймворк; это не предназначено, чтобы быть полноценной структурой DI. Если вам не нужны компоненты, заменяемые в режиме реального времени, изучите полную структуру контейнера DI / IoC . Unity - альтернатива Microsoft.
  • Убедитесь, что вы не выполняете анти-шаблон Service Locator . Используйте конструктор внедрения интерфейсов всякий раз, когда это возможно. Смотрите этот замечательный пост Марка Симанна и этот пост Джимми Богарда . Ваше заявление о том, что вы «максимально используете контейнер», вызывает беспокойство - немногие классы должны знать что-либо о контейнере.
  • Получите действительно хорошую среду для насмешек и изоляции и научитесь ее использовать. Я люблю Moq . Старайтесь по возможности проверять состояние в тестируемой системе, а не проверять поведение в макете.
  • Читать Искусство модульного тестирования . Читайте другие книги и статьи по модульному тестированию. Практика TDD . Продолжайте учиться.
  • Прочитайте Очистите код и убедитесь, что ваши классы следуют принципам SOLID (особенно Принцип единой ответственности ). Длительная ложная настройка - это запах кода; ваши занятия, вероятно, делают слишком много. Высокий охват кода хорош, но лучшим показателем может быть цикломатическая сложность .
  • Не беспокойтесь о том, что ваши модульные тесты занимают больше времени, чем производственный код. Относитесь к тестам как к производственному коду и устраняйте дублирование всякий раз, когда вы можете сохранить удобочитаемость и удобство обслуживания.
0 голосов
/ 06 июня 2010

Вот несколько хороших ссылок о DI и хороших методах проектирования (с точки зрения написания тестируемого кода), которые вы, возможно, захотите проверить (Google Tech talk):

Я нашел их очень полезными с множеством полезных советов по тестируемому дизайну.

...