How to TDD a Reporting Application?

[fsharpmike]

Hi,

    Could anyone provide any pointers on how to go about developing a
reporting application using TDD?  That is, an application that is
focused on reading from different tables in the database, combining
the data in various ways, then formatting and outputting it?

Thanks,
Mike

[Carl Manaster-2]

Hi, Mike,

Think about it this way:

If your program was already written and running, what test could you
write that demonstrated it was working?

If that's too big a step, pick a little piece - say, "combining the
data in one of the various ways" - and write a test for that.  Say one
of your various ways was concatenation.  assertEquals("",
ConcatenationCombiner.combine("", ""));

Make that pass.

assertEquals("a", ConcatenationCombiner.combine("a", ""));

Make that pass.

assertEquals("a", ConcatenationCombiner.combine("", "a"));

Make that pass.

assertEquals("ab", ConcatenationCombiner.combine("a", "b"));

Make that pass.  OK, ConcatenationCombiner is done.  Any opportunities
yet for refactoring?  No?  Ready for a bigger step?  No?  Test-drive
your next Combiner.  Or Formatter.  Or DataRetriever, etc., etc.

Repeat until done.  Alternate red and green to move forward.

Peace,
--Carl


On 3/1/08, fsharpmike <fsharpmike@...> wrote:
> Hi,
>
>     Could anyone provide any pointers on how to go about developing a
>  reporting application using TDD?  That is, an application that is
>  focused on reading from different tables in the database, combining
>  the data in various ways, then formatting and outputting it?
--
http://undisclosed-recipients.blogspot.com
http://www.flickr.com/photos/carlmanaster/sets/228603/

[ulu]

--- In testdrivendevelopment@..., "fsharpmike"
<fsharpmike@...> wrote:

>
> Hi,
>
>     Could anyone provide any pointers on how to go about developing a
> reporting application using TDD?  That is, an application that is
> focused on reading from different tables in the database, combining
> the data in various ways, then formatting and outputting it?
>
> Thanks,
> Mike
>

I'm developing Inka (http://sourceforge.net/projects/inka) using TDD
from the very beginning (I learned a lot doing that). My goal was,
however, to create a reporting tool that is independent of its data
source.

Anyway, first I wrote a simple test that verified that a string is
printed at the specified position. I used TypeMock and mocked the
Graphics object. I wrote an expectation that the method DrawString
should be called, with appropriate arguments. After I made it pass, I
refactored the code and got rid of the Graphics dependency. Now I can
write my tests against a mocked ICanvas interface. Which is good,
since I can write implementations for printing and exporting to pdf
and stuff. However, my next step was to get rid of this dependency
too, since I didn't want to print something each time I want to test
it. So, I refactored it into a preparation stage, where all elements
are assigned their values and placed at the correct positions, and the
actual printing stage. Now the preparation is completely independent
of the printing.

After that I started more refactoring. I made each element
independent, so that I can create it without creating the whole
report, and check its properties. For example, a data-driven element
should have its Value correct given the correct data source and
format. It should be testable without creating the whole report, or
even the parent section. on the other hand, the layout should be
testable independently of the concrete elements. So, while adding new
features, I'm going from testing the big picture to smaller units, but
I still have the first test to make sure that everything is wired
together correctly.

One big mistake was not introducing the paging engine early. After I
was finished with one-page layout, I discovered that implementing
paging requires much re-design, and in the process many existing tests
began to break. Was it the flaw of the TDD process? I believe that
adding the paging capabilities was not an additional feature, but
rather change of the requirements. Also, my mistake was to put a lot
of design decisions (versus client requirements) into tests.

ulu

[Carfield Yim-2]

I think Ron have 2 articles about this, but I haven't read very
detail, not sure if that really fit

http://www.xprogramming.com/xpmag/dbcLjuticMonoGun.htm
http://www.xprogramming.com/xpmag/dbcLjuticRefactoring.htm

On Sun, Mar 2, 2008 at 2:16 AM, fsharpmike <fsharpmike@...> wrote:

>
>
>
>
>
>
> Hi,
>
>  Could anyone provide any pointers on how to go about developing a
>  reporting application using TDD? That is, an application that is
>  focused on reading from different tables in the database, combining
>  the data in various ways, then formatting and outputting it?
>
>  Thanks,
>  Mike
>
>  

[fsharpmike]

Hi,

    I appreciate the responses.  What I'm really having trouble with
is testing the database.  Specifically, setting up the test data.  For
the first time ever I'm considering mocking test data, which I've
always been loathe to do, but this data is so complex, and I'm only
reading it, so it might not make sense to do actual database inserts
in this case.  Thoughts?

Thanks,
Mike

[Kelly Anderson]

Did you happen to read the post on DbFit this morning? I dunno, but it
might help.

-Kelly

On Mon, Mar 10, 2008 at 1:44 PM, fsharpmike <fsharpmike@...> wrote:

> Hi,
>
>  I appreciate the responses. What I'm really having trouble with
>  is testing the database. Specifically, setting up the test data. For
>  the first time ever I'm considering mocking test data, which I've
>  always been loathe to do, but this data is so complex, and I'm only
>  reading it, so it might not make sense to do actual database inserts
>  in this case. Thoughts?
>
>  Thanks,
>  Mike
>

[George Dinwiddie]

fsharpmike wrote:
> Hi,
>
>     I appreciate the responses.  What I'm really having trouble with
> is testing the database.  Specifically, setting up the test data.  For
> the first time ever I'm considering mocking test data, which I've
> always been loathe to do, but this data is so complex, and I'm only
> reading it, so it might not make sense to do actual database inserts
> in this case.  Thoughts?

Have you looked at dbunit?  Though, for testing reporting, I think I'd
rather mock the data access layer than insert into the database.  That,
of course, is without knowing your context.

  - George

--
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------

[Donaldson, John (GEO)]

Well, without adding dbfit to the mix, I'll propose keeping it simple.
First you run nearly all of your tests up to, but no further, the db abstraction layer (you do have one right?). Then to test the abstraction layer, really use the database - but set up a transaction for each test, and roll it back at the end.

John D.

> -----Original Message-----
> From: testdrivendevelopment@...
> [mailto:testdrivendevelopment@...] On Behalf Of fsharpmike
> Sent: Monday, March 10, 2008 8:44 PM
> To: testdrivendevelopment@...
> Subject: Re: [TDD] How to TDD a Reporting Application?
>
> Hi,
>
>     I appreciate the responses.  What I'm really having trouble with
> is testing the database.  Specifically, setting up the test data.  For
> the first time ever I'm considering mocking test data, which I've
> always been loathe to do, but this data is so complex, and I'm only
> reading it, so it might not make sense to do actual database inserts
> in this case.  Thoughts?
>
> Thanks,
> Mike
>
>
>
>
> Yahoo! Groups Links
>
>
>