Где разместить повторно используемые методы тестирования, используемые в нескольких тестовых классах Grails

Question

Мне часто нужно настраивать одни и те же тестовые структуры для разных тестовых случаев. Поэтому я создал класс TestService, который имеет несколько открытых методов для тестовых классов.

Полагаю, это не лучшее место для их размещения, поскольку TestService также будет развернут, хотя и не нужен на производстве.

Куда бы вы положили эти обычные методы испытаний? Есть ли «лучшая практика» для этого?

Answer 1

То, как я это делаю, похоже на приведенные выше ответы.Если у меня есть класс MyDomain, я помещаю класс MyDomainTestHelper в тестовый пакет.У помощника есть статические методы, которые возвращают рассматриваемые доменные объекты.Так что у меня может быть

static createTestMyDomain() {...}

, который создает экземпляр с разумными значениями по умолчанию и

static createTestMyDomain(String something)

, чтобы я мог что-то указать и т. Д.

Вы не должны ставитьих в «службе», как вы упомянули.Но любой способ быть СУХИМ - это хороший способ.

Answer 2

Я стараюсь придерживаться принципа DRY столько, сколько могу при написании тестов. Это показывает в основном двумя способами:

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

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

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

Answer 3

Почему бы вам не поставить его рядом с тестовыми классами?Обычный способ - поместить весь связанный с тестами код в каталог, отдельный от исходного каталога (например, «тест»).Т.е. не только сами тестовые примеры, но и поддерживающие классы, такие как служебные методы, фиктивные реализации и т. Д.

Тестовые примеры должны быть помещены в тот же пакет, что и класс, тестируемый ими (но в другомкаталог, как объяснено выше).Тестовый класс утилит, который используется несколькими тестовыми примерами, должен быть помещен в некоторый общий пакет утилит.