2015-09-09 7 views
1

У меня есть класс, который анализирует данные с html-страницы и превращает ее в коллекцию String. В основном у меня есть URL-адрес интернет-магазина, и я хочу иметь список его элементов. Мой класс имеет следующую подпись:Лучший способ проверить hardcoded данные

public static List<String> getShopItems() 

обычно метод возвращает очень большой список (4k пунктов или больше). Мой вопрос в том, как я могу проверить этот метод? Я думаю, что я должен утверждать, что возвращенный список имеет правильный размер и содержит все необходимые элементы. Но было бы очень утомительно создавать List с элементами 4k и сравнивать фактические и ожидаемые списки. Кроме того, элементы могут измениться в будущем, и мой тест не удастся.

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

ответ

1

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

  • сократить перечень необходимых предметов (я предполагаю, что нет 4k разные случаи?)
  • гарантировать, что данные не изменятся
0

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

+0

Если списки должны быть отсортированы, зависит от намерения теста, я думаю –

0

Я обычно разделить эти тесты вверх на 2 части:

  1. тестирования функции тщательно устанавливает базовый/малые данные
  2. тестирования некоторые основные свойства с реальными данными

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

Basic Test

Try, чтобы получить покрытие коды 100% с этим испытанием, испытанием для обработки ошибок, а также для недостоверных данных. Используйте несколько наборов данных для этого теста и убедитесь, что все выходные данные верны.

Real тестовых данных

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

Теперь вы должны быть творческими в своих тестах: попробуйте утверждать для свойств данных. Примерами могут быть (попробуйте выбрать несколько!):

  1. Все цены в прейскуранте должны быть положительными.
  2. Нет ошибок, связанных с вашей исчерпывающей проверкой ошибок в функции.
  3. Проверьте количество элементов. Для реальных данных сделайте это смутно, поскольку поддельные данные проверяют точное число.
1

Во-первых, статические методы, подобные этому, почти всегда являются плохой идеей, они затрудняют тестирование.

Во-вторых, интерфейс Resource может действительно помочь в тестировании таких случаев. например:

public interface Resource { 
    InputStream getStream(); 
} 

Тогда вы могли бы реорганизовать класс быть что-то вроде:

public class ShopItemProvider { 
    private final Resource resource; 

    public ShopItemProvider(Resource resource) { 
     this.resource = resource; 
    } 

    @Override 
    public List<String> getShopItems() { 
     try (InputStream in = resource.getStream()) { 
      return someFancyParseMethod(in); 
     } 
    } 
} 

Теперь у вас есть крюк, что нужно для тестирования. В тестовом примере вы можете объединить InputStream с несколькими записями в нем, возможно, используя тестовый файл из тестового пути.

В процессе производства InputStream может исходить из URL-адреса или файла или, возможно, для какого-либо ресурса производственного класса.

0
  1. отдельный метод, который получает данные от метода, анализирующие данные, так что вы можете проверить различные входы (метод синтаксического анализа следует принимать строку или поток, а не URL)
  2. сделать очень детальные тесты с помощью пользовательских, небольшие входы. это должна быть ваша основная часть тестирования
  3. вы можете сделать снимок веб-страницы, сохранить ее локально и использовать ее для проверки реальных данных. обновить этот файл при изменении структуры страницы
  4. Последняя часть - интеграционные тесты. подключитесь к реальной веб-странице и убедитесь, что ваш парсер не генерирует исключения, если он все еще дает некоторый разумный вывод (например, список, превышающий 1k элементов), проверьте, не изменилась ли структура страницы. не проверяйте точное содержимое списка, поскольку страница может измениться. также не включайте интеграционные тесты в свои модульные тесты, поскольку иногда страница может быть недоступна, сеть может быть недоступна и т.д.
Смежные вопросы