Overlooking an easy choice . . .

Please enter <something>

Conrad Weisert, July 17, 2011

On-line dialogs

In reviewing a couple of programming textbooks, I recently came upon the use of extended online dialogs in temporary test-driver code. The pattern was:

  1. Issue a prompt message ("Please enter . . . ")
  2. Read data from the keyboard or a script file.
  3. Be prepared (or not) to handle exceptions caused by bad input.

Now a simple dialog is an effective way to obtain input from a user. In some situations it may even be the most efficient and reliable way. But there are two things wrong with what those books are trying to teach a student to do:

  1. Modern users have become so accustomed to forms-driven input, that they're likely to view such a dialog, if it gets into a production program, as "old fashioned" or "user unfriendly".

  2. The dialog in these examples was directed not at an end user of a product, but at a person testing a module, either the original programmer or someone else close to the code. (Does a programmer really need to say "please" to himself or to a script?)
All that, then, is just wasted effort, an antipattern.

The simple alternative

It's interesting that the authors' examples overlook the easiest and most natural way of obtaining low-volume input. Every C++ or Java program invoked from the console contains a main program that looks like this:

C++ Java 
  int main(int argcount, char* args[])
     {
     }
 
 public static 
     void main(String [] args)
      {
      }

Surprisingly, one book I was reviewing, despite showing the args parameter hundreds of times, never suggested what it might be used for. Yet the examples launched right into that old-fashioned console dialog just to obtain a file name or some other run parameter.

Note that command-line parameters are long established for the commands and utility programs in mainstream operating systems. Imagine how annoyed you'd be if you wanted to make a copy of a file and typed: copy and then saw on your screen: Please enter the name of the file you want to copy.

If the tester-user is going to run your program from the command line anyway, then command-line parameters are the natural way to provide one or two pieces of input information. Conducting a dialogue is silly and annoying.

Impact on test automation

One of the same books that draws heavily upon the Please enter . . approach also advocates automating your tests. It's easy to package command-line invocations with parameters in a batch procedure or script, so that anyone can rerun the exact test cases you used at any time. It's harder to do that if the test session involved a human user at a keyboard.

Last modified 22 July 2001

Return to technical articles .
Return to IDI home page.