ћы в Telegram - чате. “ы с нами? 😎

ћерион Ќетворкс

4 минуты чтени€

Ќасколько часто вы попадаете в замкнутый цикл из ошибок при разработке приложени€ в PHP? ќшибка исчезает, а потом по€вл€етс€ в другом блоке кода, или баги посто€нно смен€ют друг друга. —амое непри€тное обсто€тельство - вернутьс€ к багу, который был исправлен несколько часов назад.  огда отлаживание алгоритма начинает приносить раздражение - о конструктивном подходе к задаче можно забыть. »менно дл€ того, чтобы не дать вам забросить перспективную разработку или просто выполнить поставленную задачу, существует возможность использовать PHPUnit тестирование.


„то такое PHPUnit тестирование?

— Unit или же "модулем" плотно св€зано понимание процесса тестировани€. ћодуль - это работающа€ часть кода, функционал которой можно протестировать автономно. —оответственно, PHPUnit тестирование представл€ет собой последовательную проверку всех модулей приложени€ на корректность выполнени€ их алгоритмов.

“есты можно прописать один раз и впоследствии использовать после внесени€ любых изменений.

ѕреимущества модульного тестировани€

¬от несколько неоспоримых преимуществ Unit-тестировани€:

  1. ќперативна€ проверка правок. ƒовольно удобно провер€ть работоспособность модул€ немедленно после его изменени€. ќпераци€ займет несколько секунд.
  2. ќблегченна€ передача кода другому разработчику. ≈сли вы прекратили разработку продукта и ее продолжит другой специалист, то процесс передачи пройдет намного легче.
  3. Ѕезопасное редактирование. ≈сли вы боитесь, что изменени€ модулей могут повлечь за собой глобальную проблему дл€ системы в целом, то без предложенного Unit-тестировани€ обойтись будет очень сложно.

»спользование PHPUnit тестировани€

 PHPUnit

»спользовать модульное тестирование достаточно просто. Ќиже будет описано, как установить и запустить первый тест.


”становка

Ёлементарный способ установить библиотеку PHPUnit - выгрузить его по каналу PEAR. ƒл€ этого нужно вписать:

"1 pear config-set auto_discover 1"
"2 pear install pear.phpunit.de/PHPUnit"

ƒл€ пользователей, которые хот€т иметь углубленное понимание по этому процессу подойдет ручной вариант установки через официальный сайт PHPUnit.


«апуск

Ћюбой тест запускаетс€ при помощи вызова команды phpunit. ”кажите php-файл как в примере ниже:

"1 phpunit /path/to/tests/RemoteConnectTest.php"

ѕосле этого, запущенный тест вернет результат:

"1 PHPUnit 2.5 by Aloizii MagaRich"
"2 ."
"3 Time: 1 second"
"4 Tests: 1, Assertions: 1, Failures 0"

»тог представл€ет из себ€ краткие статистические данные по работе теста, такие как врем€ операции, количество тестов, утверждений и ошибок.

“акже во второй строке можно заметить знак ".", сигнализирующий о том, что тест завершилс€ успешно. Ёто общий итог операции. Ќиже представлены другие варианты вывода, если тест:

  • "F" - не выполнен.
  • "I" - невозможно закончить.
  • "S" - пропущен.

—тандартные тесты

“акже приведем список стандартных вариантов тестировани€, которые можно использовать в 80% ситуаций. Ќазвание каждого теста начинаетс€ с упом€нутого ранее утверждени€ или Assert:

  • "True/AssertFalse". »спользуетс€ дл€ вы€влени€ корректности значений на соответствие true/false.
  • "Equals". ѕровер€ет равенство.
  • "GreaterThan". —опоставл€ет переменные (присутствует большее количество вариаций этого сравнени€).
  • "Contains". “естирует правильность содержани€ переменной.
  • "Type". »сследует тип переменной.
  • "Null". ѕровер€ет равенство null.
  • "FileExists". ѕодтверждает существование файла.
  • "RegExp". “естирует регул€рность выражени€.

ћодульное тестирование: почему нет?
 ћодульное тестирование PHPUnit

ѕочему все разработчики не используют PHPUnit тестирование? «акономерный вопрос, когда дело касаетс€ такого эффективного инструмента. ¬от несколько распространенных причин:

  1. “естирование затратно по времени. Ќаписание строк с тестом занимает врем€, которое можно было уделить построению общей структуры приложени€. ќднако в конечном счете продукт будет дополн€тьс€. Ќесколько часов добавлени€ теста на раннем этапе сэкономит больше времени на стадии доработки или сопровождени€.
  2. »спользовать модульные тесты - скучно.  онечно, прогон€ть проверку каждого модул€ в большой разработке - это рутина, особенно по сравнению с ее созданием. Ќо поддержка 100% работоспособности - это элемент такта, который может позволить себе только насто€щий профессионал.
  3. ”веренность в то, что код будет работать без проверок. ¬озможно, что автор досконально знает свой код и может оперативно исправить любой баг. ќднако если с приложением будет работать другой человек, то не факт, что он сможет вникнуть во все нюансы так же быстро.

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


ѕолезна ли ¬ам эта стать€?


Ёти статьи могут быть вам интересны: