Что такое единичные тесты и почему меня это беспокоит?

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

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

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

Учитывая качество большей части кода PHP, который я видел, я бы сказал, что модульное тестирование определенно имеет свое место в сообществе PHP. Тем более, что практически на любом другом языке. 😉

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

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

• Тестовые примеры . Способы группировать подобные тесты вместе, часто проверяя один и тот же файл или раздел кода.
• Функции Setup / teardown : функции, которые вызывают перед каждым тестом, что настройка и состояние очистки одинаковы для нескольких тестов.
• Функции утверждения : функции, которые позволяют утверждать, что определенные вещи верны, например, значение равно другому ожидаемому значению, что значение истинно / ложно и т. Д. Когда они терпят неудачу, они показывают, какие ожидаемые и фактические значения были ,
• Приложение с запущенным тестированием : приложение, которое выполняет все ваши тесты для вас один за другим, показывая, были ли они успешными или неудачными, а если это не удалось, какие конкретные утверждения не удались и каково фактическое значение в отличие от ожидаемого значения.

Единичные тесты полезны по нескольким причинам:

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

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

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

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

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

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

Модульные тестовые рамки для PHP содержат PHPUnit и SimpleTest , которые были сопоставлены с StackOverflow .

Большинство php, которые я видел, почти невозможно выполнить модульное тестирование.

В Википедии есть статья об модульном тестировании, если вы заинтересованы.

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

С другой стороны, автоматическое тестирование модулей основывается на том, что у вас есть какая-то форма приложения / упряжи для запуска и повторного тестирования. С помощью автоматических модульных тестов вы можете повторно запускать тесты, просто нажав кнопку. Так почему же повторять тест так важно? Проще говоря, вы не пишете приложения, которые запускают тесты на них один раз, а затем уходят от них. Напишите свои тесты, чтобы вы выполняли свой код в отдельных небольших тиражах и запускали их на протяжении всего процесса разработки. Делая это, с хорошо написанным набором тестов, у вас гораздо больше шансов идентифицировать код, который был нарушен обновлениями.

По поводу того, почему в первую очередь необходимо провести единичное тестирование, я хотел бы добавить аргумент Барри Бема: «обнаруженная и исправленная ошибка на этапе модульного тестирования более чем в сто раз дешевле, чем если бы это было сделано после поставки на клиент."

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

Поиск Google для «тестирования модуля php» дает сокровищницу информации по этому вопросу. Проект PHPUnit выглядит интересным.