Лучшие практики: структурирование модульных тестов - PullRequest
3 голосов
/ 20 мая 2009

Я немного растерялся. Получил проект, который покрыт юнит-тестами в разных сборках. Со-разработчик создал еще один проект + еще один сборочный модуль. Теперь мы хотим смешать некоторую логику между обоими проектами модульных тестов (объектные фабрики, некоторые задачи инициализации, помощники внедрения / насмешки и т. Д.). Это приведет к тому, что его проект будет ссылаться на мои сборки.

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

Ответы [ 2 ]

3 голосов
/ 20 мая 2009

Конечно, есть разные подходы, не существует единого «правильного пути». Вот как мы структурировали наши тесты:

У нас есть «модули» в нашем продукте, которые состоят из нескольких сборок. Для каждого «модуля» у нас есть одна сборочная тестовая единица и одна сборочная тестовая сборка. Мы ссылаемся на тестовые сборки от других таким образом:

  • «базовые» модульные тесты ни на что не ссылаются. Он также содержит вспомогательные классы для юнит-тестов.
  • ссылка на базовые тесты интеграции "core". Он содержит дополнительные интеграционные тесты вспомогательных классов (например, материал базы данных)
  • Справочник по модульным испытаниям модуля X. Базовые испытания по ядру
  • Интеграционные тесты "модуля X" могут ссылаться на модульные тесты "модуля X" и тесты "ядра"

Тесты "модуля X", конечно, никогда не ссылаются на тесты "модуля Y".

1 голос
/ 20 мая 2009

Обоснование того, почему вы должны помещать модульные тесты в отдельные сборки, состоит в том, чтобы предотвратить смешивание тестового кода с рабочим кодом. Сборки обеспечивают четкое разделение проблем и делают его достаточно гибким, чтобы вы могли удалить тесты, когда они не нужны. Например. когда вы отпускаете, конечный пользователь не заинтересован в загрузке всего тестового кода, когда он / она хочет использовать только конечный результат.

Относительно наличия множества тестовых сборок (по одной на каждую сборку "фактического кода") является вменяемой идеей. Добавление ссылок между тестовыми сборками не так сложно, и на самом деле помогает избежать слишком частого перепутывания кода, поскольку вам не нужно много ссылок (т.е. зависимостей) между сборками.

Также не пытайтесь использовать слишком много общей логики для модульных тестов, потому что для этого нужны модульные тесты / макеты / DI! Наличие большого количества пользовательских фабрик в тестовом коде является хорошим показателем того, что вы сделали производственный код слишком сложным, чем он должен быть.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...