Unit Testing

I am working on an application that was fairly well underway before I discovered the idea of unit testing. I don't want to go back and re-write the whole thing, but I think I may want to incorporate unit testing. I have a few questions and would really appreciate any suggestions you can make.

Although I try to practice pretty clean programming and most of my procedures are probably less than a dozen lines, some of them are out of control and probably run 70 to 80 lines. I'm using Delphi, I have started putting some tests within a couple of the units at the bottom of the unit within a region that is surrounded by conditional defines. This part of the code only gets compiled when I open the unit with my test project. Is this a good approach? Maybe after I do a few hundred tests I can get a feel for it, but I am unsure how to write tests that will fail at the right time. Can you recommend a book or an article out there that shows a lot of samples? How do I test my out of control procedures? Do I need to rewrite them first? Any suggestions for sort of wading into this?

My application runs in an interactive mode and also in a batch mode where it takes its data from a file. I can set up and run a big job in a few minutes that might take days to do interactively. I used to use tax preparation software where I spoke sometimes to some members of the development team. One person told me they had several tax returns from hell that they tested their program with. If if did not produce the right results, they knew it immediately. With an application like mine that will run in batch mode, it seems like this might be a valid testing practice. What do you think? What would I get from unit testing that I would not get from this?

Sorry this is so long. Many thanks for your thoughts.

-Jack

Payroll Developer
Monday, October 29, 2007

Deleting …Approving …

Heh! 70 to 80 lines for a module? That's not "out of control". A 300 to 1000 line module, THAT'S "out of control".

And I assume you mean "automated Unit Testing" -- I can't believe you've been delivering code without testing it. Not code that works, anyway.

AllanL5
Monday, October 29, 2007

Deleting …Approving …

I dunno, 70-80 lines for a procedure is pretty damn big in my world. True, I've seen worse.

What you will get if you don't unit test is:- Greater number of integration test failures- More time spent tracking down errors

As for your existing code, the main rule to use is "let sleeping code lie". If you've written code without unit tests, don't touch it till it breaks. Then refactor it and write unit tests. Otherwise, if it ain't broke, don't touch it.

Finding and installing dUnit is the easy part of this. It simply provides you with a convenient framework to apply the tests. Deciding what to test and how to do it are where the real work is. I think I can get started on the hard part with this material.

Payroll Developer
Tuesday, October 30, 2007

Deleting …Approving …

==>70-80 lines for a procedure is pretty damn big in my world.

How do you folks do this? Seriously.

By the time you add in error checking/exception handling, basic logging features, some data validation, maybe an assert/debug here or there, some perfomance counters, a bit of extra "defensive coding" -- by the time you add it all in you've got 80 lines of cruft before you even get to the working part of the procedure.