Экранный скребок поблочного тестирования

Чтобы создать ваши модульные тесты, вам необходимо знать, как работает ваш парсер и какую информацию, по вашему мнению, он должен извлекать. Использование простых веб-страниц в качестве модульных тестов может быть приемлемым в зависимости от сложности вашего парсера.

Для регрессионного тестирования вы должны обязательно хранить файлы на диске.

Но если вашей конечной целью является очистка Интернета, вы также должны вести учет общих запросов и возвращаемого HTML-кода. Таким образом, когда ваше приложение выходит из строя, вы можете быстро захватить все прошлые интересующие запросы (используя, скажем, wget или curl ) и выяснить, изменился ли HTML и как.

Другими словами, регрессионный тест как против известного HTML, так и против неизвестного HTML из известных запросов. Если вы выдаете известный запрос, и возвращаемый HTML будет идентичен тому, что '

Файлы в порядке, но: ваш скребок экрана обрабатывает текст. У вас должны быть различные модульные тесты, которые «очищают» различные фрагменты текста, жестко закодированные в каждом модульном тесте. Каждая деталь должна «спровоцировать» различные части вашего скребкового метода.

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

Вам нужно подумать о том, что вы скребете.

• Статический HTML (HTML, который не обязательно должен кардинально измениться и сломать ваш скребок)
• Динамический HTML (Свободный термин, html, который может кардинально измениться)
• Неизвестно (HTML, из которого вы извлекаете определенные данные, независимо от формата)

Если HTML статический, то я бы просто использовал пару разных локальных копий на диске. Поскольку вы знаете, что HTML-код не обязательно должен кардинально измениться и сломать ваш парсер, вы можете с уверенностью написать свой тест, используя локальный файл.

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

Теперь, если вам просто все равно, в каком формате HTML, порядок элементов или структура, потому что вы просто извлекаете отдельные элементов, основанных на каком-либо механизме сопоставления (Regex / Other), тогда может быть подойдет локальная копия, но вы все равно можете склоняться к тестированию с живым html. Если live html изменится, особенно части того, что вы ищете, то ваш тест может пройти, если вы используете локальную копию, но при развертывании может произойти сбой.

Я считаю, что протестируйте против live html, если вы можете . Это предотвратит прохождение ваших локальных тестов, когда живой HTML может дать сбой, и наоборот. Я не думаю, что есть лучшая практика со скрэперами, потому что скрэперы сами по себе необычные маленькие жукеры.

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

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

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

Если вам нужно проверить большое количество разных вещей в модульном тесте, возможно, вам будет лучше генерировать вывод HTML как часть вашего тестовая инициализация. Он по-прежнему будет основан на файлах, но у вас будет расширяемый шаблон:

Initialize HTML file with fragments for Test A
Execute Test A
Delete HTML file

Таким образом, когда вы добавите тест ZZZZZ в будущем, у вас будет согласованный способ предоставления тестовых данных.

Если вы просто запускаете ограниченное количество тестов, и так и будет, несколько предварительно написанных статических файлов HTML подойдут.

Конечно, проведите некоторые интеграционные тесты, как предлагает Рич.

Похоже на вас здесь есть несколько компонентов:

• Что-то, что извлекает ваш HTML-контент
• Что-то, что удаляет мусор и создает только текст, который необходимо очистить
• Что-то, что действительно просматривает контент и преобразует его в вашу базу данных / что угодно

Вы должны протестировать (и, возможно,) реализовать эти части скребка независимо.

Нет причин, по которым вы не должны иметь возможность получать контент откуда угодно (например, без HTTP).

Там '

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

Почему бы не создать проект TestContent, заполненный кучей файлов ресурсов? Скопируйте и вставьте исходный HTML-код в файл (ы) ресурсов, а затем вы можете ссылаться на них в своих модульных тестах.

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

Я не понимаю, почему с точки зрения ваших модульных тестов имеет значение, откуда берется HTML-код. Чтобы уточнить: ваш модульный тест обрабатывает html-контент, откуда этот контент не имеет значения, поэтому чтение его из файла подходит для ваших модульных тестов. как вы говорите в своем комментарии, вы, конечно, не хотите подключаться к сети для каждого теста, поскольку это просто накладные расходы.

Вы также можете добавить один или два интеграционных теста, чтобы проверить, правильно ли вы обрабатываете URL-адреса (т.е. вы можете подключаться и обрабатывать внешние URL-адреса).

Для моих скреперов ruby ​​+ Mechanize я экспериментировал с интеграционными тестами, которые прозрачно тестируют максимально возможное количество возможных версий целевой страницы.

Внутри тестов я перегружаю Метод HTTP-выборки scraper для автоматического повторного кеширования более новой версии страницы в дополнение к "исходной" копии, сохраненной вручную. Затем каждый интеграционный тест запускается с:

• исходной сохраненной вручную страницей (что-то вроде модульного теста)
• самой свежей версией страницы, которая у нас есть
• живая копия с сайта прямо сейчас (которая пропускается, если offline)

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