The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

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.

Payroll Developer Send private email
Monday, October 29, 2007
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.
Monday, October 29, 2007
I dunno, 70-80 lines for a procedure is pretty damn big in my world. True, I've seen worse.

Your last paragraph isn't really describing unit testing. That's integration/functional/acceptance testing. Unit testing only tests individual methods/procedures.

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.
Monday, October 29, 2007
Payroll - Do you know about DUnit?
IanH. Send private email
Tuesday, October 30, 2007
Thank you for your comments.  I kept looking online and found a couple of articles over at CodeProject. 

The first one called "Writing Your First Unit Test" at has several suggestions based on where you are in the development of your project.  It has similar advice as Bruce who suggested not disturbing working code.

The second one I found at is actually 5 articles.  These articles, along with the first one, are just what I was looking for. 

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 Send private email
Tuesday, October 30, 2007
==>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.

There's no way for a production app that I can keep 'em small.
Tuesday, October 30, 2007
+1 Sgt.Sausage

and probably some inline comments too.

Joannes Vermorel Send private email
Tuesday, October 30, 2007
Dear Sgt.Sausage

It depends on the language that you are using.  For Java and C#, 70-80 lines is long (not too long yet), and should/can be shorten by extracting out to small methods.

Generally, what I find is that long methods usually contain unnecessary branching and doing much more that what the "method" is described to do.

9 out of 10 times, I will also say 70-80 also too long should be made smaller in other languages as well.  Each language has its own "number of lines" before considerd to be out of control.

BTW, I am not considering any performance impact, it is purly for readability.
Wednesday, October 31, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz