just to clarify what winston is saying, it sounds a bit vague to me, but a driver is a temporary module that is written to call (and yes, test) modules below. sometimes, especially in bottom-up design, lower-level modules are written prior to higher level ones. these modules may not run as standalone items and so a driver must be written to run the module. The driver will be a very simple piece of code, that simply calls the procedure/function with any required parameters and may output the parameters to the screen when the procedure has been run. in terms of testing, the driver can be used to thoroughly test the module, even before the higher level module has been written, i.e. various test data can be fed in as parameters and compared with expected output