Модульное тестирование скребка экрана

Question

Я нахожусь в процессе написания скребка экрана HTML. Каков наилучший способ создания модульных тестов для этого?

Это нормально, иметь статический HTML-файл и читать его с диска при каждом тесте?

Есть ли у вас какие-либо предложения?

Answer 1

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

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

Answer 2

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

Внутри тестов я перегружаю метод выборки HTTP скребка, чтобы автоматически повторно кэшировать более новую версию страницы, в дополнение к «оригинальной» копии, сохраненной вручную. Затем каждый интеграционный тест выполняется с:

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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

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

Answer 5

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

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

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

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

Между прочим, у меня была намного лучшая очистка экрана удачи с тех пор, как я перестал пытаться очищать необработанный HTML и вместо этого начал очищать вывод w3m -dump, который является ASCII и который намного проще разобраться с!

Answer 6

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

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

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

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

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

Нет смысла хранить данные в вашей базе данных только путем очистки.

Итак ... нет причин создавать и тестировать все эти фрагменты кода как одну большую программу.

Опять же ... может быть, мы слишком усложнили ситуацию?

Answer 7

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

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

Answer 8

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

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

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

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

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

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

Answer 9

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

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

Answer 10

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