Где вы поместите свой unit test?
Я нашел несколько условных обозначений для тестов на обслуживание в проекте и
Я не уверен, какой подход подходит для нашего следующего проекта PHP. я
пытаясь найти лучшее соглашение, чтобы способствовать
доступность тестов при просмотре исходного кода. Я был бы очень
заинтересованы в вашем опыте/мнении относительно каждого:
- Одна папка для продуктивного кода, другая для модульных тестов: это отделяет
модульные тесты из логических файлов проекта. Это разделение
опасения - такая же неприятность, как и преимущество: кто-то смотрит в
исходный код проекта будет - я полагаю, - либо просмотрите
реализации или модульных тестов (или чаще: реализация
только). Преимущество модульных тестов - это еще одна точка зрения на ваши классы
потеряно - эти две точки зрения находятся слишком далеко друг от друга.
- Аннотированные методы тестирования: любая современная модульная система тестирования, которую я знаю, позволяет
разработчикам создавать специальные методы тестирования, аннотировать их (@test) и
встраивая их в код проекта. Большой недостаток, который я вижу здесь, заключается в том, что
файлы проекта становятся загроможденными. Даже если эти методы разделены
используя заголовок комментария (например, UNIT TESTS ниже этой строки), он просто раздувается
класс без необходимости.
- Проверить файлы в тех же папках, что и файлы реализации: Наш файл
Соглашение об именах диктует, что файлы PHP, содержащие классы (один класс
на файл) должен заканчиваться на .class.php. Я мог представить, что помещение
тесты относительно файла класса в другой, заканчивающийся на .test.php, будут
сделать тесты гораздо более интересными для других разработчиков, не испортив
класс. Хотя он раздувает папки проекта, а не
файлы реализации, это мой любимый до сих пор, но у меня есть сомнения: я
подумали бы, что другие уже придумали это, и отбросили это
по какой-то причине (т.е. я не видел Java-проект с файлами
Foo.java и FooTest.java в той же папке.) Может быть, потому, что
Разработчики java более активно используют среды IDE, которые позволяют им более легкий доступ к
тесты, в то время как в PHP нет больших редакторов (например, eclipse for
java) - многие разработчики, которых я знаю, используют vim/emacs или аналогичные редакторы с небольшим количеством
поддержка разработки PHP как таковой.
Каков ваш опыт в любом из этих мест размещения unit test? У тебя есть
другое соглашение, которое я здесь не перечислял? Или я просто переоцениваю unit test
доступность рецензентам?
Ответы
Ответ 1
Я предпочитаю хранить модульные тесты в отдельных исходных файлах в том же каталоге, что и производственный код (# 3).
Единичные тесты не являются гражданами второго сорта, их код должен поддерживаться и реорганизоваться точно так же, как производственный код. Если вы проводите тесты устройств в отдельном каталоге, следующий разработчик, чтобы изменить ваш производственный код, может пропустить, что для него есть отдельные тесты и не удается выполнить тесты.
В С++ я имею тенденцию иметь три файла для каждого класса:
MyClass.h
MyClass.cpp
t_MyClass.cpp
Если вы используете Vim, то может оказаться полезным мой toggle_unit_tests плагин для переключения между исходными и unit test файлами.
Ответ 2
Текущая лучшая практика заключается в том, чтобы отделить модульные тесты в их собственный каталог, №1. Все системы "конвенции по конфигурации" делают это так, например. Maven, Rails и т.д.
Я думаю, что ваши альтернативы интересны и действительны, и поддержка инструментов, безусловно, там, чтобы их поддерживать. Но это просто не так популярно (насколько я знаю). Некоторые люди возражают против того, что тесты чередуются с производственным кодом. Но для меня имеет смысл, что, если вы всегда пишете модульные тесты, они будут расположены прямо с вашим кодом. Это просто кажется более простым.
Ответ 3
Я всегда за # 1. Хотя приятно, что они близки друг к другу. Мои причины следующие:
- Я чувствую там разницу между базовой кодовой базой и unittests. Мне нужно настоящее разделение.
- Конечным пользователям редко приходится смотреть на unittests. Они просто интересуются API. Хотя приятно, что unittests предоставляют отдельное представление о коде, на практике я чувствую, что он не будет использоваться, чтобы лучше понять его. (более описательная документация + примеры).
- Поскольку конечным пользователям редко нужны unittests, я не хочу путать их с большим количеством файлов и/или методов.
- Мои стандарты кодирования не являются строгими для unittests, как и для основной библиотеки. Возможно, это просто мое мнение, но в моих тестах меня не волнует стандарт кодирования.
Надеюсь, что это поможет.