Тестирование устаревшего кода спагетти PHP?

Ответ 1

Я бы, наверное, начал тестировать с помощью инструмента, такого как Watir или Selenium. Это позволит вам выполнять проверку черного ящика всей страницы автоматически. После того, как вы настроили эти тесты, вы можете начать рефакторинг страниц PHP и создать модульные тесты, когда вы выполняете рефакторинг.

Ответ 2

Во-первых, PHPUnit можно использовать для простого тестирования процедурного кода. Не позволяйте факту, что примеры PHPUnit показывают только классы, которые вас удерживают. Именно так организованы тесты PHPUnit.

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

Если код не работает на PHP 5.2+, то вы не можете использовать текущую версию PHPUnit, которая определенно больше беспокоит, и моя первая общая рекомендация - найти любые проблемы, которые может принести обновление PHP 5.

Чтобы начать с одной рекомендации книги, чтобы избавить вас от некоторых проблем:

Working Effectively with Legacy Code

Книга поможет вам избежать множества мелких ошибок, которые вам придется сделать самостоятельно, и вы получите правильное мышление. Это основано на Java, но это не проблема, так как большая часть материала легко адаптируется.

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

Приобретение тестов модулей выполняется довольно долго и не дает вам статус "все еще работает", поэтому мой первый момент состоял бы в том, чтобы установить некоторые интеграционные и интерфейсные тесты.

Инструменты, такие как Selenium, а веб-части тестирования Behat могут помочь вам LOT с этим.

Преимущество использования Behat заключается в том, что вы можете написать хорошую документацию для того, что должен делать продукт. Независимо от того, как выполнить проект, эти документы всегда будут иметь значение для вас.

Остальные читают что-то вроде: "Когда я перехожу к этому URL-адресу и вводю эти данные, пользователь должен быть создан, и когда я нажимаю там, я получаю электронное письмо, содержащее мой экспорт данных". Проверьте это. Это может быть полезно.

Самое главное - получить быстрый зеленый/красный индикатор, если вещь все еще работает!

Если вы затем узнаете, что он был сломан, несмотря на то, что ваш свет был зеленым, вы можете расширить тесты оттуда.

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

После того, как у вас есть общее представление о том, как все работает, и вы доверяете своим маленьким тестам, чтобы показать вам, когда вы нарушаете "все это", я бы сказал, что пришло время создать небольшую Сервер непрерывной интеграции, например Jenkins для PHP, который позволяет отслеживать состояние вашего проекта с течением времени. Вначале вам не нужны все материалы QA (возможно, чтобы получить обзор по проекту), но, просто увидев, что все "все еще работает", "возвращает", "очень важно", и экономит много времени, из этого вручную.

2% Покрытие кода скучно

Когда вы находитесь в момент, когда в модуле тестируются модульные тесты и охват кода, вы столкнетесь со средним значением 0%. Это может быть очень раздражающим, чтобы никогда не видеть, чтобы это число сильно увеличилось.

Но вы хотите, чтобы вы проверили новый код, поэтому я предлагаю использовать PHP_Change_Coverage как described in this blog posting убедитесь, что все, что вы касаетесь, испытывает впоследствии.

PHP Black Magic

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.';
?>

Ответ 3

Устаревший код без модульных тестов всегда является болью. Там нет реального решения, потому что большую часть времени код не написан таким образом, что он полностью тестируется. На работе нам пришлось обрабатывать много устаревшего кода. Мы написали модульные тесты для нового написанного кода (что тоже больно, потому что вам нужно настроить некоторые тестовые данные и тому подобное). Таким образом, это не ухудшится, и вы будете покрывать все более старый старый код, который вызывается в вашем новом коде. Выполняя это, вы каждый раз становитесь ближе к коду, который покрывается модульными тестами.

Ответ 4

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

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

Вы должны также убедитесь, что вы на самом деле проверяете этот новый код. Различия в новых записях (вы используете исходный контроль, если нет, FIX THAT FIRST!) Против старого, вы можете увидеть, что изменилось и получить точную информацию о местоположении изменений. Вы (ну, ваш менеджер должен) хотят доказать, что эти изменения были протестированы. Вы можете использовать инструмент покрытия кода, чтобы сообщить, что было протестировано, и пересечь его с расположением ваших новых изменений; лучше всего пересечься весь модифицированный код. Наш PHP Test Coverage может предоставлять информацию о покрытии и может вычислять такие данные пересечения.