Маркировка юнит-тестов

Question

Я работаю над проектом PHP с полным охватом юнит-тестов.

Я заметил, что в прошлый раз я совершал очень хитрые манипуляции с модульными тестами Командная строка Test Runner ' - команда фильтра .

Вот объяснение этой команды из официальной документации:

- фильтр

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

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

Мне интересно, хорошая ли это практика или нет?

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

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

Я понимаю, что "настоящие" юнит-тесты не должны взаимодействовать с БД, использовать объекты mock / stubs, я согласен с этим. Но иногда гораздо проще (дешевле) использовать приборы БД для тестов.

Пожалуйста, дайте мне несколько советов, как решить эту проблему?

Answer 1

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

Мне интересно, хорошая ли это практика или нет?

Конечно, если вы время от времени запускаете полный набор юнит-тестов (через CI-сервер звучит идеально)

Регулярно запускать "интересные" тесты лучше, чем редко запускать все тесты ..

Answer 2

Хорошие юнит-тесты должны:

• Иметь понятные имена методов и имен переменных для использования в качестве документации
• Беги быстро. Это также будет возможно для теста со сложным делом логика. Тест должен выполняться в среднем время чего-то около 0,1 секунды.
• Проверка ровно одной вещи в одном методе испытания
• Не интегрируется с внешними ресурсами, такими как файловая система, электронная почта, базы данных, веб-сервисы и все остальное. Вы можете создать отдельные тесты интеграции базы данных чтобы проверить вашу базу данных. Этот тест будет медленнее, чем ваш блок тестировать большую часть времени. Я положил интеграционные тесты в отдельном проект, и я запускаю их только тогда, когда я работает над кодом интеграции. я также запустить их на всех сборках на CI сервер.
• Быть полностью изолированным друг от друга. Когда у вас есть тесты в зависимости друг на друга, вы не можете увидеть, что ваша проблема заключается в чтении которого тесты не пройдены. Возможно, вам придется отладка, чтобы найти проблему. изолированный тесты сэкономят вам много времени.

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

Реакция на:

"Но иногда это очень проще (дешевле) использовать светильники БД для тесты. "

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

Лично я научился тестировать лучше

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

Answer 3

Я бы решил проблему, имея подмножество тестов («тесты дыма»), которые занимают 1 минуту или меньше, прежде чем должен быть запущен перед фиксацией, а затем запустите полный набор тестов из вашего CI. сервер.

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

Затем вы можете использовать --filter для запуска тестов, которые вас больше всего интересуют, затем тестов дыма перед фиксацией, а остальные запустить с сервера CI.