Question

I’m thinking of the case where the program doesn’t really compute anything, it just DOES a lot. Unit testing makes sense to me when you’re writing functions which calculate something and you need to check the result, but what if you aren’t calculating anything? For example, a program I maintain at work relies on having the user fill out a form, then opening an external program, and automating the external program to do something based on the user input. The process is fairly involved. There’s like 3000 lines of code (spread out across multiple functions*), but I can’t think of a single thing which it makes sense to unit test.

That’s just an example though. Should you even try to unit test ‘procedural’ programs?

*EDIT

Answer 1

Based on your description these are the places I would look to unit test:

• Does the form validation work of user input work correctly
• Given valid input from the form is the external program called correctly
• Feed in user input to the external program and see if you get the right output

From the sounds of your description the real problem is that the code you’re working with is not modular. One of the benefits I find with unit testing is that it code that is difficult to test is either not modular enough or has an awkward interface. Try to break the code down into smaller pieces and you’ll find places where it makes sense to write unit tests.