||Home » About LReport
Welcome on LReport project home page
LReport is a toolkit for comparing data stored in databases and in
csv files. It is written in perl and can be used as command line
utility or a perl modules from your code.
LReport also provides tools, which support nice formating of data retrieved from the database or csv files.
The project is hosted on Source Forge.
If you have any comments please post a message in project's forums.
For quick start go to tutorial.
What is LReport
I started writing LReport as a tool supporting me in my
job as a tester. The initial goal was to create a script,
which will run a given select and will nicely format it's
results. When you test business applications, documenting
database contents is a necessity and a pain.
In the course of implementation I have realized, that a task
can be divided on 2 parts - retrieving and comparing data,
and formating them. Those 2 tasks can be done independently.
- The comparison is done by lcsvdiff.pl, which compares row sets (stored in database or in csv files).
- Formating is done by a tool-chain - lrptxml.pl, which converts
row set to xml file and then a set of xsl stylesheet converts the xml to RTF format document
In all projects I was in as a tester, documenting database contents was always a
problem. When you think about it, there are 2 extrema. One extremum is
that you put in your report only data, which you consider important.
That means that you report only important tables and only important
columns of these tables.
On the other side, you can report all
tables, which may be affected by executed actions and if you report any
table, you report all columns.
Whatever the approach, reports are
created by copying and pasting selects' results from tools like
OraTool, Rapid SQL, SqlPlus, isql etc. This way of doing things works
fine for many projects, but I believe there is some space for
significant improvement here.
The common approach I was describing above has the following problems
and pasting is a tedious and boring task (hence, error prone),
especially if you require to report contents of many tables.
- It is very easy to miss
differences between before and after test state of the data.
- There is a contradiction between
readability and completness of the report
I think that the
first and the second point needs no further explanation. However, the
you place only selected columns from selected tables, nicely formated -
then your report is readable. But there are 2 problems with going this
- It is time consuming. Instead of "select *" you have
type "select column1, column2, ...etc". No big deal if you do it once
for one table. It becames a problem if you have to explicitly specify
columns for several tables. Also nice formating is time consuming. It
is not going to take much time to convert copied and pasted stuff into
tables and apply some shading and coloring once. But if you are
executing several test cases, this time becomes significant.
is a risk that you miss some data, which were actually important. Later
on when you analyze the test case, you will realize that some tables or
columns contained really important data. But it will be to late. The
data will be gone
Pasting all columns from many
tables has the advantage of completness. But this kind of reports are
hardly readable, especially when you report many tables and some of
them contains 80 or more columns.
So the design goals for LReport was to:
Automaticaly create nicely formated reports from selected tables.
- Automate finding differences between results of the group of selects
Find a solution to readability vs completeness contradiction
- Ease of use