Модульные тесты для вывода HTML?

Это может быть глупым вопросом, но вы делаете модульные тесты для вывода HTML своих функций / скриптов PHP?

Я стараюсь, чтобы мой HTML и мой PHP были разными – например, HTML включает в себя с помощью заполнителей и функции для определенных повторяющихся элементов (табличные данные / любые циклические выходные данные), но я не уверен, как это сделать.

Есть ли стандартный способ решения таких вопросов, или это главным образом вопрос использования стандартных модульных тестов для функций, которые создают вставленный контент, а затем, чтобы убедиться, что он выглядит корректно в браузере / W3C Validator?

Благодарю.

Редактирование: Я думаю, что следствием этого было бы: есть ли подобные тесты, даже заслуживающие внимания? Если вы правильно разделяете свой контент и структуру, тогда вы действительно будете тестировать только несколько включений в очень ограниченных сценариях (предположительно, во всяком случае). Действительно ли это стоит для полных страниц полных рук, чтобы иметь файл для сравнения?

Основываясь на моем опыте тестирования HTML, я теперь следую этим трем основным правилам:

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

2. Проверьте наличие важных данных в сгенерированном HTML. Если вы создаете HTML (в отличие от статического HTML, который вы пишете один раз), протестируйте сгенерированный HTML для важных данных. Например: если вы создаете таблицу на основе двухмерного массива, проверьте, что значения в массиве находятся где-то в сгенерированном HTML. Не утруждайте себя проверкой полного вывода, так как это нарушит №1.

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

Эта библиотека PHP позволит вам проверить правильность строки HTML5. В библиотеке используется Validator.nu. Совместимость с PHPUnit или любой другой средой тестирования.

Скачать и документацию здесь.

Прост в использовании, например:

$validator=new HTML5Validate(); // Validate (returns TRUE or FALSE) $result=$validator->Assert('<p>Hello World</p>'); // Get explanation of what's wrong (if validation failed) print $validator->message;

Тестирование на выход HTML будет рассматриваться как тест покрытия. Первоначально, когда я начал использовать PHP, я создавал эти тесты, но со временем я обнаружил, что эти тесты не были действительно полезными.

Если есть одна вещь, которую я знаю, это то, что презентация сильно изменится с начальной разработки до развертывания.

Если вы думаете об этом, цикл for действительно не является логическим, а является изометрической функцией преобразования, и если вы следуете Separation of Concerns , то вы передаете данные в цикл for через какой-то метод. Я бы рекомендовал проверить, что цикл for получает правильные данные, но не выход цикла for.

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

На этом этапе вы должны смотреть на разделение итерации на выход HTML, чтобы помочь изолировать себя от этих проблем в ваших тестах.

Один из способов сделать это – использовать функцию сопоставления, он возьмет функцию списка и преобразования и выполнит функцию для каждого элемента в списке, а затем вернет преобразованный список.

Обычно, создавая таблицы, я получаю две строки для создания строки.

Итерации по всем строкам.
В то время как в (1) перебирать элементы в строке.

Довольно уродливый для модульного теста, но с закрытием вы можете создавать генераторы функций, которые действительно были бы легкими [это сказано с зерном соли] для реализации.

Вы можете использовать PHPUnit. Он имеет выходное тестирование.

http://www.phpunit.de/manual/3.0/en/testcase-extensions.html

Я нашел, что Framework SimpleTest очень полезен, обычно я использую его для интеграционных тестов и PhpUnit для модульных тестов. Они избавили меня от многих поданных вручную формуляров, и я буду делать это снова и снова.

Стало моей привычкой следовать этим моментам при проведении таких тестов интеграции:

Старайтесь не повторять тесты, которые уже выполняются с помощью реальных модульных тестов. Если, например, у вас есть проверенная на модуле функция проверки адресов электронной почты, нет смысла отправлять все виды недействительных адресов электронной почты. Проверяйте только один раз, если вы перенаправлены с сообщением об ошибке.
Не сравнивайте полученный HTML с полным ссылочным результатом, вам придется обновлять свои тесты при каждой редизайне ваших страниц. Вместо этого проверьте только критические части с помощью $webTestCase->assertText('...'); или $webTestCase->assertPattern('/.../'); ,

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

 public static function openPageWithNoWarnings($webTestCase, $page, $landingPage = null) { // check that page can be opened successfully $webTestCase->assertTrue($webTestCase->get($page)); // check that there are no PHP warnings $webTestCase->assertNoPattern('/(warning:|error:)/i', 'PHP error or warning on page!'); // check if landed on expected page (maybe a redirect) if (!empty($landingPage)) { $url = $webTestCase->getUrl(); $file = basename(parse_url($url, PHP_URL_PATH)); $webTestCase->assertEqual($page, $file, sprintf('Expected page "%s", got page "%s".', page, $file)); } }

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

Существует расширение для PHPUnit, которое выполняет проверку html здесь: https://github.com/xvoland/html-validate

Забегая на этот вопрос сам. Я думаю, что подход может состоять в том, чтобы использовать что-то вроде phpQuery, чтобы ваши тесты были менее хрупкими. Вместо тестирования для точного вывода проверьте, что на выходе должен быть тэг h3 ~ где-то ~. Если он будет завернут в div позже, потому что дизайнеру нужно было наложить дополнительный фон или из-за некоторого обходного пути с ошибкой ie6, тогда ваш тест все еще работает.

Это не очень чистый, но все же потенциально очень полезный инструмент.

В некоторых случаях (например, помощники CakePHP) целью класса или функции является создание для вас согласованного HTML. В таких случаях важно проверить, что ожидаемые свойства сгенерированной единицы HTML правильны для данных входов. Вопрос определенно важен в этом контексте.

Для этой цели PHPUnit предоставляет функцию assertTag () .

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

Один очень простой способ сделать это – это буферизация вывода.

например

 ob_start(); function_which_produces_some_output(); $this->assertEquals( ob_get_clean(), '<p>Expected Output Here</p>');