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

50

Я растущий программист, который наконец применяет модульное тестирование на практике для библиотеки, которую я храню на GitHub.

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

Это считается плохой формой? Является ли идея, что пользователи интересуются только рабочим кодом и что они все равно будут тестировать в своей собственной среде?

version-control unit-testing parisminton
источник
13
Почему нет? Тесты должны идти вместе с проектом, или они практически бесполезны.
61
Тот факт, что некоторые проекты не включают модульные тесты в свой репозиторий, более вероятен из-за отсутствия таких тестов.
прасопы
4
Они построены отдельно, но в остальном u-тесты тесно связаны с кодом. Для обеспечения согласованности должно быть какое-то управление зависимостями. Будь то помещение их в один и тот же репозиторий, суб-репозиторий или поддержку управляемой версией «ссылки» на тестовый репозиторий и т. Д.
2012 г.
2
@stoupa совершенно определенно прав: было бы неплохо предположить лучшее, что где-то спрятан замечательный тайник тестов, но в реальном мире программисты ленивы.
Каскабель
2
Обратите внимание, что я считаю хорошей идеей отключить компиляцию тестового класса в вашем скрипте сборки.
user606723

Ответы:

119

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

Однако тестовый код должен быть хорошо отделен от рабочего кода. Например, Maven достигает этого, помещая рабочий и тестовый код в разные папки. Вопрос «является ли этот файл частью производственного или тестового кода» никогда не должен возникать.

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

сигнальная башня
источник
1
В качестве другого примера, взгляните на папку тестирования ipython . Если кто-то проверит это, независимо от того, куда он его поместит, относительные ссылки для тестов все еще остаются верными. Это делает его тривиальным, что важно для определения того, правильно ли настроен ваш новый компьютер.
Спенсер Рэтбун
Тесты являются не только частью кода, но и частью документации, а часто и частью спецификации. Тесты (которые проходят и проходят) являются «живой документацией».
Майкл Пасха
54

Если вы не включите модульные тесты в зарегистрированный исходный код, то:

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

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

CVn
источник
7

Конечно, вы должны поместить в хранилище модульные тесты по нескольким причинам:

  • легко вернуться к предыдущей версии
  • другие люди, работающие над проектом, также получают доступ к модульным тестам
  • некоторые люди считают модульные тесты частью документации (TDD и BDD)
BЈовић
источник
6

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

Я сильно подозреваю, что большинство проектов, которые не включают тесты в хранилище, просто не имеют их.

Может быть причина иметь тесты как отдельный модуль, чтобы вы могли легко запускать новые тесты со старым кодом. Это было бы полезно для API-стабильной библиотеки или тестов черного ящика через командную строку; Полезность для компилируемых языков, где новые тесты, вероятно, не будут компилироваться со старым кодом, ограничена.

Ян Худек
источник
5

Абсолютно. Дополнительные бонусные баллы заключаются в возможности отслеживать, что версия X исходного файла соответствует версии Y теста. Другими словами, вы должны иметь возможность вернуться к предыдущей версии и получить соответствующие тесты, разработанные для этой версии (в случае изменения API или некоторого такого).

скоро
источник
3

Я только что закончил читать «Разработка приложений Brownfield в .Net» , и это дает некоторые отличные рекомендации по структуре приложения, включая контроль исходного кода и где / как / почему включать модульные тесты (особенно в области непрерывной интеграции). , Если вы разработчик .Net, я бы порекомендовал это.

seanfitzg
источник