Project's page
Project's forum
Documentation
RTF example documents
FAQ
Tutorial's package
The project is hosted on Source Forge. You can find the details and some documentation here.
If you have any comments please post a message in an appropriate project's forum.
If you want to contact me personaly, you can reach me at pkaluski@users.sourceforge.net.
What is LReport
The purpose
There are different methodologies describing how to create test cases, how to manage them. But regardless on the methodology, execution of most of test cases (in business applications) looks like this: Check the interesting database tables, run test scenario, check interesting tables again and document your observations.
The purpose of LReport is to help you with the checking and documenting phase.
The problem
In all projects I was in, 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:
- Copying 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
third does.
If you place only selected columns from selected tables, nicely formated - then your report is readable. But there are 2 problems with going this way.
If you place only selected columns from selected tables, nicely formated - then your report is readable. But there are 2 problems with going this way.
- It is time consuming. Instead of "select *" you have to 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.
- There 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:
1. Automaticaly create nicely formated reports from selected tables.
2. Automate finding differences between results of the group of selects
3. Find a solution to readability vs completeness contradiction
4. Ease of use
In short, this is
how I have done it:
- There is a tool chain allowing to generate csv files from selects' results and to compare those csv files.
- Both csv files and difference report can be converted to XML files
- You can then format the report using XSL. Currently conversion to RTF is supported.