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

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

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

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

Спасибо!

ОТВЕТЫ

Ответ 1

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

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

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

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

Манж

Ответ 2

Я создал пару unit test для тестирования.

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

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

  • Для рендеринга: я не нашел подходящего подхода для этого. Кто-нибудь получил идеи?

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

Ответ 3

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

Задача

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

Ответ 4

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

Привет

Фрэн

Ответ 5

Что касается подхода PDFbox для проверки содержимого PDF-документов: я только что открыл проект open-source 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>

Ответ 6

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

Для третьего этапа проверки проблем рендеринга я экспортирую отчет в 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)