Как я могу протестировать отчет о яшме?

Я хочу протестировать все отчеты о яшме моего приложения. Я хочу иметь возможность обнаруживать:

  • Проблемы с компиляцией (подойдет ли для этого проверка того, что JasperCompileManager.compileReport(some inputStream) не выдает JRException?)
  • Проблемы с заполнением (подойдет ли для этого проверка того, что JasperFillManager.fillReport(someReport, someParameters, someDataSource) не выдает JRException?)
  • Проблемы с рендерингом: обнаружение появления «пустых» строк, усечение текста в экспортированном PDF-файле.
  • Любая другая идея?

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

Спасибо!


java unit-testing testing jasper-reports
person Community    schedule 04.08.2010    source источник

Ответы (6)


arrow_upward
3
arrow_downward

Для проблем с компиляцией и для проблем с заполнением: Да, вы можете сделать как описано и просто попробовать скомпилировать и заполнить отчет. Если это не вызывает исключение, то все в порядке.

Для третьего шага проверки проблем с рендерингом я экспортирую отчет в XML:

String xml = JasperExportManager.exportReportToXml(
    JasperFillManager.fillReport(report, params, dataSource)
);

Теоретически XML является точным представлением файла PDF, но в формате, легко читаемом в тестах. Например. если поле слишком длинное и его содержимое усекается, оно также усекается в XML. Все значения уже находятся в формате «рендеринг», поэтому, если вы, например. есть число, которое вы форматируете с помощью шаблона (DecimalFormat), тогда число будет отформатировано в XML. Кроме того, идентификаторы uuid для полей все еще присутствуют в XML, поэтому вы также можете легко найти поля. Чтобы проверить поле, вы можете, например. сделать что-то вроде:

hasXPath("//*[@uuid = '" + field.getUuid() + "']/../*[local-name() = 'textContent']", matcher)
person yankee    schedule 03.07.2017

arrow_upward
2
arrow_downward

Я создал пару модульных тестов для тестирования аспектов.

  1. Проблемы с компиляцией: я создал класс для загрузки и компиляции всех моих шаблонов. Моя среда основана на Интернете. Поэтому я также проверил путь через это.

  2. Для заполнения: я издевался над данными и JRDataSource, чтобы заполнить шаблон, который мне подходит.

  3. Для рендеринга: я не нашел хорошего способа сделать это. У кого-нибудь есть идеи?

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

person garfiny    schedule 19.04.2011

arrow_upward
1
arrow_downward

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

Я нашел следующую ссылку полезной,

http://flexingcode.blogspot.com/2009/04/junit-for-jasper-reports.html

Надеюсь, это поможет,

Манджу

person Manjum    schedule 10.08.2010
comment
Ссылка больше недоступна - person Bogdan Kobylynskyi; 15.05.2017
comment
Его на archive.org, но изображения повреждены. Однако общее представление вы все же можете получить. - person Pixelstix; 23.03.2021

arrow_upward
1
arrow_downward

Для автоматической компиляции вы можете попытаться скомпилировать отчеты с помощью сценария Ant (см. 1 или http://jasperreports.sourceforge.net/api/net/sf/jasperreports/ant/package-summary.html)

Задача Ant подходит для использования в системах автоматического построения или непрерывной интеграции, таких как maven или jenkins.

person Michele Milesi    schedule 22.04.2011

arrow_upward
1
arrow_downward

Одним из подходов к рендерингу может быть экспорт отчета в PDF, а затем использование чего-то вроде PDFBox (Apache) для проверки содержимого. Также вы можете сделать то же самое с экспортом в файл Excel, а затем использовать Apache POI или JExcelAPI для проверки содержимого ячейки.

С уважением

Фрэн

person frandevel    schedule 21.07.2014

arrow_upward
1
arrow_downward

Что касается подхода PDFbox к тестированию содержимого PDF-документов: я только что обнаружил проект с открытым исходным кодом jPdfUnit, который очень помогает:

Ознакомьтесь с документацией здесь: http://jpdfunit.sourceforge.net/docs/GettingStarted.html< /а>

Он основан на junit 3 и не поддерживается годами, но он просто работает. Одна настройка, которую мне пришлось применить, чтобы заставить ее работать, заключалась в том, чтобы установить версию pdfbox на 1.8.13. Просто введите это в свой, если вы используете maven:

<dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.apache.pdfbox</groupId>
                <artifactId>pdfbox</artifactId>
                <!-- jpdfunit is not compatible with pdfbox 2 (java5 vs java6) -->
                <version>1.8.13</version>
            </dependency>
        </dependencies>
</dependencyManagement>
person Jasper Vandaele    schedule 16.12.2016