Subj : DevDrive/IntHand vs. applications (was: Not debugging?)
To   : comp.programming,comp.lang.java.programmer,comp.lang.lisp
From : rem642b
Date : Fri Sep 02 2005 11:29 pm

> From: Greg Menke <gregm-xyz...@toadmail.com>
> Its quite hard and maybe impossible to write unit tests for some
> (new) things; OS bootloaders, device drivers, interrupt handlers, etc.

In some such cases I'd recommend putting the absolute minimum amount of
code into the device driver or interrupt handler itself, putting all
the complicated stuff in an application that invokes the low-level
driver directly. Things may run slowly that way, but it's relatively
easy to debug. Later when you get confidence that your application code
(emulating higher functions of device driver) is solid, you can try
miagrating it into the driver.

> Unit tests are great, but they also have their limits.

I agree. I do application programming, where line-by-line and
each-function unit testing works great 99% of the time. That's the kind
of programming where I strongly recommend that method of program
development. In the case of tools used locally, exactly that method
(which I've described in more detail elsewhere, and which I teach to
absolute beginners) works all the way up to the very top level. In the
case of tools used via CGI applications, nearly all the tools can be
developed in a read-eval-print (Lisp or java/BeanShell), all but the
very toplevel application. That latter requires a slightly different
interaction:
- REP: Get test input, code&execute first line of code, use that
already existing data to execute second line of code, etc.
- CGI-toplevel: Write test rig to get test input, and print it, and
load WebPage to execute it. Add first line of code, and print
statement, re-load WebPage, which re-executes the get-test-input and
runs the first line of code for first time. Add second line of code,
and print statement, re-load WebPage, which re-executes get-test-input
and first-line and runs second line of code for the first time. Etc.
keep adding more lines of code and re-loading to re-do everything old
and first-time-do everything new. Since the test input usually comes
from a HTML FORM, it's trivial to test other input merely by changing
the contents of the form and re-submitting it. One nice thing about the
Web is that it's easy to jump to the end of the output, so you don't
have to worry about too much print statement output before the final
result, and if there's a problem you can then scroll back easily to see
the earlier print outputs.

(Remarks about CGI apply equally to JSP, PHP, etc., but not to Java
HttpServlets where you have to compile and install each new version
before you can run it, but even then the modular nature of Java and
automatic compile-only-what-changed and dynamic runtime loader makes it
not too horribly painful if you can compile directly to the runtime
directory and thereby avoid needing to run deploytool each time.)

.