Пока у нас есть только два теста для Array и встроенная функция sizeof(). Когда мы начинаем тестировать большое количество функций array_*(), нам нужен тест для каждой из них. Мы можем написать каждый из них с нуля. Однако лучший подход — написать тестовую инфраструктуру один раз, а затем писать только разные части каждого теста. PHPUnit является такой инфраструктурой.
В примере 5 показано, как переписать два теста из примера 4 с помощью PHPUnit.
Пример 5. Протестируйте Array и sizeof() с помощью PHPUnit
.
require_once 'PHPUnit2/Framework/TestCase.php';
класс ArrayTest расширяет PHPUnit2_Framework_TestCase {
общественная функция testNewArrayIsEmpty( ) {
//Создаем приспособление массива.
$фикстура = Массив( );
// Утверждаем, что размер фикстуры массива равен 0.
$this->assertEquals(0, sizeof($fixture));
}
общественная функция testArrayContainsAnElement( ) {
//Создаем приспособление массива.
$fixture = Array( );
// Добавляем элемент в массив.
$fixture[] = 'Элемент';
//Утверждаем, что размер фикстуры массива равен 1.
$this->assertEquals(1, sizeof($fixture));
}
}
?>
В примере 5 рассказывается, что основные шаги по использованию PHPUnit для написания тестов:
1. Тестовый класс для класса Class — ClassTest.
2. ClassTest обычно наследует PHPUnit2_ Framework_TestCase.
3． Test — это общедоступный метод без параметров, его имя — test*.
4. В методе тестирования функции утверждения, такие как AssertEquals() (см. Таблицу 6), используются для проверки того, соответствует ли фактическое значение ожидаемому значению.
Такой фреймворк, как PHPUnit, должен решать ряд проблем, некоторые из которых, похоже, конфликтуют друг с другом. Тесты также должны соответствовать следующим условиям:
Легкость в освоении
.Тесты должны быть простыми в освоении, иначе разработчики не будут учиться.
Легко разрабатывать.
Тесты должны быть простыми в разработке, иначе разработчики не будут разрабатывать.
Легко читать.
Тестовый код не должен иметь внешних связей. , чтобы сам тест не затерялся в беспорядке.
Легкость выполнения.
Тесты должны быть простыми в выполнении, а результаты выполнения должны быть выражены в ясном и недвусмысленном формате.
Тестыбыстрого выполнения
должны выполняться быстро, чтобы их можно было выполнять тысячи раз в день.
Тестыизоляции кода
не могут влиять друг на друга, а изменения в порядке тестов не должны влиять на результаты.
Компонуемость
Мы должны иметь возможность запускать тесты в любой комбинации, что является следствием изоляции кода.
Между этими ограничениями существует два основных конфликта:
простота обучения и простота разработки
.Тестирование обычно не требует полной гибкости программирования. Многие инструменты тестирования предоставляют свои собственные языки сценариев тестирования. Эти языки имеют только минимальный набор функций, необходимых для написания тестов. Поскольку в содержимом теста нет шума, написанные тесты легко читать и писать. Но изучать новый почтовик и набор инструментов для вязания по-прежнему неудобно и легко запутывается.
Изоляция кода против быстрого выполнения.
Если вы хотите, чтобы результаты одного теста не влияли на другой, вам необходимо создать полную тему для теста в начале каждого теста, а затем восстановить состояние перед запуском. Однако настройка состояния занимает много времени (например, подключение к базе данных и инициализация известного состояния с реальными данными.
Решение этой проблемы в PHPUnit — использование PHP в качестве языка тестирования). Иногда полнофункциональный PHP оказывается слишком мощным для написания коротких и простых тестов, но программисты, которых мы используем, уже имеют полный опыт работы с PHP. Поскольку нам нужно убедить неохотных тестировщиков, чрезвычайно важно снизить барьер для написания этих первоначальных тестов.