«Тестирование модулей» отчет

Question

Как вы «единично тестируете» отчет, созданный некоторым механизмом отчетов, например Crystal Reports или SQL Server Reporting Services?

Answer 1

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

• Separated Presentation: Отдельного представления от содержания (данные доступа/домен/бизнес-правил). В текущем контексте это означает, что вы создаете какой-то класс ViewModel, который отражает содержимое окончательного отчета (например, если у вас есть детали заказа и позиции в отчете, этот класс должен иметь свойства для деталей и список строк объекты предметов). ViewModel бесконечно проще тестировать. Последняя миля, применяющая представление к контенту, должна быть относительно тривиальной (тонкий интерфейс).
  , например. если вы используете xslt для рендеринга своих отчетов, вы можете протестировать XML-данные с помощью таких инструментов, как XmlUnit или сравнение строк. Вы можете разумно убедить себя в преобразованиях xsl в данных xml для окончательного отчета ... Также любые ошибки здесь были бы тривиальными для исправления.
• Однако, если вы используете сторонние поставщики, такие как Crystal Reports, у вас нет контроля/доступа к подключению к генерации отчетов.В таких случаях лучшее, что вы можете сделать, это генерировать репрезентативные/ожидаемые выходные файлы (например, pdf), называемые Golden Files. Используйте это как ресурс только для чтения в своих тестах для сравнения фактического вывода. Однако этот подход очень хрупок. В этом случае любое существенное изменение кода генерации отчета может привести к неправильному отображению всех предыдущих Golden Files. Поэтому их нужно будет восстановить. Если соотношение затрат и выгод для автоматизации слишком велико, я бы сказал, что руководство Go со старыми школьными планами тестирования doc.

Answer 2

Лучшее, что я могу придумать, сравнивает результаты с ожидаемым выходом.

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

Answer 3

Я согласен с Gamecat.

Сгенерировать отчет из фиксированных (постоянных) данных и сравнить его с ожидаемым выходом для этих данных.

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

Answer 4

Для тестирования нашего собственного продукта Java на основе отчетности, i-net Clear Reports, мы проводим целую кучу протоколов испытаний один раз , экспортируя их в различные форматы экспорта, убедитесь, что результат по своему желанию, а затем непрерывно обрабатывать эти же отчеты ежедневно, сравнивая результаты с исходными данными. Любые различия тогда появляются как неудачи теста.

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

Боковое примечание: это не совсем единичный тест, а скорее тест приемочного испытания. Но я не вижу, как вы могли бы «единично тестировать» весь отчет.

Answer 5

Моя текущая идея заключается в том, чтобы создавать тесты на двух уровнях:

• испытания Единица измерения: Структура отчета, чтобы включить тестирование с использованием некоторых идей для тестирования пользовательского интерфейса, как Humble View. Сам доклад будет сделан как можно глубже. Он должен состоять в основном из простых связок полей. Затем элементы данных/объекты, которые выступают в качестве источника этих привязок, могут быть подвергнуты блочной проверке.

• Приемочные тесты: Создайте несколько отчетов о примерах. Сначала проверьте их вручную. Затем настройте автоматизированный тест, который сравнивается с использованием diff.