Должны ли классы модульных тестов находиться под контролем версий вместе с остальным кодом?

Question

Если я создаю набор тестов для проекта разработки, должны ли эти классы оставаться под контролем версий вместе с остальным кодом проекта?

Answer 1

Да, нет причин не помещать их в систему контроля версий. Что если тесты изменятся? Что если интерфейсы меняются, что требует смены тестов?

Answer 2

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

Это классический вопрос: кто, где и почему:

• Кто изменил код?
• Когда они это изменили?
• Зачем они это изменили?

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

Answer 3

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

Answer 4

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

Вы также должны держать тестовые данные под контролем источника, если они не очень большие.

Answer 5

Действительно, да. Как кто-то мог думать иначе?

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

Answer 6

Модульные тесты должны быть привязаны к базе кода в вашем хранилище.

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

Answer 7

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

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

Answer 8

Абсолютно. Вы, вероятно, обнаружите, что по мере изменения кода ваши тесты могут также нуждаться в изменении, поэтому вам, вероятно, захочется получить запись об этих изменениях, особенно если тесты или код внезапно перестанут работать. ; -)

Кроме того, модульные тестовые наборы должны быть как можно ближе к реальному коду, который они тестируют (нижняя часть того же файла кажется стандартной). Это как для удобства, так и для обслуживания.

Дополнительную информацию о том, что делает хороший модульный тест, можно найти в этом сообщении stackoverflow .

Answer 9

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

Answer 10

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