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

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

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

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

Спасибо.

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

ОТВЕТЫ

Ответ 1

Основываясь на моем опыте тестирования 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 wrong (if validation failed)
print $validator->message;

Ответ 2

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

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

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

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

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

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

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

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

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

Ответ 5

Я нашел SimpleTest framework очень полезным, обычно я использую его для интеграционных тестов и 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));
  }
}

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

Ответ 6

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

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

Ответ 7

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

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

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

Ответ 8

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

например,

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