«Юнит тестирование» отчет

Question

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

Моя текущая идея - создавать тесты на двух уровнях:

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

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

Answer 5

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

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

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