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

Хорошо, я разрабатываю веб-приложения на PHP и JavaScript, и много раз здесь, в Stack Overflow, я видел, как слово unit test проходило мимо, но нигде на веб-сайте я не смог найти удовлетворительный ответ на то, что именно a unit test есть.

Итак, что такое модульные тесты, и должен ли я, как программист PHP и JavaScript, заботиться, или они предназначены только для "реальных" языков программирования?

Ответы

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

A unit test - это тест небольшой части кода, который вы пишете. Вы проверяете его изолированно от остальной части системы, чтобы убедиться, что эта часть вашего кода работает.

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

Важно различать модульное тестирование и автоматическое модульное тестирование. Вы всегда должны unit test ваш код. Однако автоматизация ваших модульных тестов - это еще один предмет.

Ответ 5

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

Wikipedia содержит статью об модульном тестировании, если вы заинтересованы.

Ответ 6

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

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

Ответ 7

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

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