Прежде всего PHPUnit может быть использован для проверки процедурного кода просто отлично . Не позволяйте факту, что примеры PHPUnit только показывают классы, удерживают вас. Так устроены тесты PHPUnit.
Вы можете просто написать тестовые классы и протестировать свою функцию на них без каких-либо проблем, и это должно быть вашей самой маленькой проблемой:)
Если код не работает на PHP 5.2+, то вы не можете использовать текущую версию PHPUnit, что, безусловно, вызывает больше беспокойства, и моя первая общая рекомендация - найти любые проблемы, которые может вызвать обновление PHP 5.
Чтобы начать с одной книжной рекомендации, чтобы избавить вас от хлопот:
Working Effectively with Legacy Code
Книга поможет вам избежать множества мелких ошибок, которые вам придется совершить самостоятельно, и поможет вам прийти в правильное мышление. Он основан на Java, но на самом деле это не проблема, так как большинство вещей легко адаптируется.
Тестирование сложно, потому что вы даже не знаете, для чего вообще нужно приложение
Подготовка модульных тестов к запуску занимает довольно много времени и не дает вам статуса «все еще работает», поэтому моей первой задачей было бы настроить некоторые интеграционные и интерфейсные тесты.
Такие инструменты, как Selenium и компоненты веб-тестирования Behat могут помочь вам в этом.
Преимущество использования Behat заключается в том, что вы можете написать хорошую документацию для , что на самом деле должен делать продукт . Независимо от того, как проходит проект, эти документы всегда будут иметь для вас значение .
Остальные читают что-то вроде: «Когда я захожу на этот URL-адрес и ввожу эти данные, пользователь должен быть создан, а когда я нажимаю там, я получаю электронное письмо, содержащее мой экспорт данных». Проверьте это. Это может быть полезно.
Самое главное - получить быстрый зеленый / красный индикатор, если он все еще работает!
Если вы затем обнаружите, что он был сломан, несмотря на то, что ваш "индикатор" горит зеленым, вы можете расширить тесты оттуда.
Когда вы не знаете, когда он сломан, вы никогда не будете достаточно уверены в том, чтобы изменить достаточно вещей вокруг, чтобы вы могли постепенно улучшать то, что нужно исправить или изменить.
После того, как у вас есть общее представление о том, как все работает, и вы доверяете своим маленьким тестам, чтобы показать вам, когда вы ломаете «все это», я бы сказал, что пришло время настроить небольшой Сервер непрерывной интеграции как Jenkins для PHP, который позволяет отслеживать состояние вашего проекта с течением времени. Вам не нужны все элементы QA в начале (возможно, чтобы получить представление о проекте), но просто увидеть, что все «все работает» возвращает «да», очень важно и экономит много времени, обеспечивая этого вручную.
2% Покрытие кода скучно
Когда вы находитесь в точке, когда вступают в игру модульное тестирование и покрытие кода, вы столкнетесь со средним показателем 0%. Это может быть довольно раздражающим, если никогда не видеть, как это число сильно растет.
Но вы хотите убедиться, что тестируете НОВЫЙ код, поэтому я бы предложил использовать PHP_Change_Coverage как described in this blog posting, поэтому убедитесь, что все, к чему вы прикасаетесь, имеет тесты после этого.
PHP Черная магия
function stuff() {
if(SOME_OLD_UGLY_CONST == "SOME SETTING") {
die("For whatever reasons");
}
return "useful stuff";
}
При тестировании это действительно раздражает, когда ваши скрипты die() но что делать?
Переработка всех сценариев без тестов может быть более вредной, чем вообще ничего не делать, поэтому, возможно, вы захотите взломать, чтобы сначала получить тесты.
Для этого и других решений страшных вещей есть расширение php test helpers.
<?php
set_exit_overload(function() { return FALSE; }
exit;
print 'We did not exit.';
unset_exit_overload();
exit;
print 'We exited and this will not be printed.';
?>