тестирование старых кодов с помощью phpunit - PullRequest
Новая
       31

тестирование старых кодов с помощью phpunit

4 голосов
/ 06 апреля 2011

У меня есть устаревшая кодовая база, и мне нужно протестировать этот код с помощью PHPUnit. Поэтому я прошу предложения, основанные на вашем опыте. Какие классы я должен проверить в первую очередь? Или отдать приоритет?

Должен ли я начать с легких / маленьких классов или с базового / суперкласса?

Ответы [ 3 ]

10 голосов
/ 06 апреля 2011

Мое общее предложение для введения модульного тестирования в существующую кодовую базу будет следующим:

  1. Начало тестирования некоторых очень простых классов, чтобы прочувствовать написание тестов
  2. Может быть, даже переписать эти тесты еще раз и сделать из них примеры "вот как мы должны это делать"
  3. Возьмите один из самых больших и подлых классов во всей системе и протестируйте этот класс как можно лучше. Это важный шаг, чтобы показать всем в вашей команде (и, возможно, руководству), что модульное тестирование вашей кодовой базы МОЖЕТ РАБОТАТЬ и выполнимо.

После этого я бы предложил вам сосредоточиться на трех вещах:

  • Убедитесь, что новый код проходит тестирование
  • Если вы исправили ошибку, создайте тест, прежде чем исправлять его, чтобы «доказать», что ошибка действительно исправлена ​​
  • Используйте тесты в качестве инструмента, когда вы касаетесь / меняете старый код, чтобы улучшить качество покрытия тестов.

PHPUnit предоставит вам отчет CodeCoverage, показывающий, насколько хорошо протестирована ваша кодовая база. Может быть довольно круто наблюдать, как число увеличивается с 0,3% до 5% до 20% в течение месяца, но это не очень сильный мотиватор.

Чтобы убедиться, что вы тестируете НОВЫЙ код, я рекомендую использовать PHP_Change_Coverage как described in this blog posting

Этот инструмент поможет вам в создании значимых отчетов о покрытии, поскольку он показывает только NEWLY CREATED CODE as UNTESTED, а не все старые вещи, которые у вас есть.

С этим у вас есть кое-что, что позволяет очень легко «получить высокий процент очень рано и продолжать тестировать новый материал», пока вы создаете тесты для всего старого.

Перед охватом изменений PHP: http://qafoo.com/blog/images/phpccov_without_timerange.png

и после: http://qafoo.com/blog/images/phpccov_with_timerange.png

5 голосов
/ 06 апреля 2011

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

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

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

Один из способов помочь решить, что следует рассматривать при тестировании, заключается в использовании инструмента покрытия тестов.Обычно это используют для определения того, насколько хорошо протестировано программное обеспечение, но если у вас мало тестов, которые вы уже знаете, оно скажет вам: ваш код не очень хорошо протестирован: - {Так что нет смысла запускать его раньше.в вашем тестовом процессе строительства.(По мере того, как вы будете проходить дополнительные тесты, вы и ваши менеджеры со временем захотите это знать).Тем не менее, инструменты покрытия тестов также имеют тенденцию предоставлять полные списки кода, который был выполнен или нет как часть ваших тестов, и , который предоставляет подсказку о том, что вы должны тестировать узел: код, который имеет не было выполнено.

Наш SD инструмент тестирования PHP PHP работает с PHP и предоставит эту информацию как через интерактивное средство просмотра, так и в виде сгенерированного отчета.Он скажет вам, какие методы, классы, файлы и подсистемы (по иерархии каталогов) были протестированы и в какой степени.Если файл с именем «login.php» не был протестирован, вы сможете легко это увидеть.И это явное представление позволяет намного легче разумно решить, что тестировать дальше, чем просто угадывать, основываясь на том, что вы знаете о коде.

0 голосов
/ 14 апреля 2015

Посмотрите на PHPure ,

Их программное обеспечение записывает входные и выходные данные с рабочего сайта php, а затем автоматически записывает тесты phpunit для функций, которые не обращаются к внешним источникам (базы данных, файлы и т. Д.).

Это не 100% решение, но хорошее начало

...