Как вы организуете свои юнит-тесты в TDD?

Question

Я делаю TDD, и я довольно свободно организовывал свои юнит-тесты. Я обычно начинаю с файла, представляющего следующую историю или часть функциональности, и пишу все юнит-тесты, чтобы это работало.

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

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

(Обратите внимание, что я задаю не столько вопрос о том, сколько утверждений на функцию): Сколько модульных тестов я должен написать для каждой функции / метода? Я говорю о увеличенное изображение.)

Answer 1

Разделите свои тесты на 2 набора:

• функциональные тесты
• юнит-тесты

Функциональные тесты для каждого пользователя. Модульные тесты для каждого класса. Первый проверяет, что вы действительно поддерживаете историю, второй - упражнение и документируете свою функциональность.

Существует один каталог (пакет) для функциональных тестов. Модульные тесты должны быть тесно связаны с функциональностью, которую они выполняют (поэтому они разбросаны). Вы перемещаете их и реорганизуете их по мере перемещения и рефакторинга своего кода.

Answer 2

Менее важной частью является организация тестов.

Я начну с помещения тестов в класс, который относится к тестируемому классу, поэтому у com.jeffreyfredrick.Foo есть тест com.jeffreyfredrick.FooTest. Но если для некоторого подмножества этих классов потребуется другая настройка, я переместу их в свой собственный тестовый класс. Я поместил свои тесты в отдельный каталог с исходными текстами, но сохранил их в одном проекте.

Более важной частью является рефакторинг тестов.

Да, я пытаюсь реорганизовать свои тесты, когда я иду. Цель состоит в том, чтобы удалить дублирование, оставаясь при этом декларативным и легким для чтения. Это верно как в тестовых классах, так и в тестовых классах. В тестовом классе у меня может быть параметризованный метод для создания тестового фейка (макет или заглушка). Мои тестовые подделки обычно являются внутренними классами внутри тестового класса, но если я обнаружу, что это необходимо, я вытащу их для повторного использования в тестах. Я также создам класс TestUtil с общими методами, когда это будет уместно.

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

Тесты являются кодом.

Answer 3

Для каждого класса в программном обеспечении я поддерживаю класс модульного тестирования. Классы модульного теста следуют той же иерархии пакетов, что и классы, которые тестируются.

Я храню код моего модульного теста в отдельном проекте. Некоторые люди также предпочитают хранить свой тестовый код в том же проекте в отдельном исходном каталоге, называемом «тест». Вы можете следовать тому, что вам удобно.

Answer 4

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

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

Answer 5

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

Так что для модульных тестов я обычно либо следую основной структуре кода проекта, либо (иногда, когда этого требует ситуация), вместо этого сосредотачиваюсь на функциональных областях.

Оставить их в одной куче, как вы можете себе представить, грязно и трудно поддерживать