Imagine a Long Delay...

With our conflicting schedules, Chet and I haven t worked on our XML Notepad for over a week. After a delicious lunch at California Pizza Kitchen ( http:
//www.cpk.com/ ), we went to the Michigan Union to write a little code. A quick review of the tests was all it took to get us back on track. The last test in the code base was this one, a precursor to a real customer test, in CustomerTest.cs:

 [Test] public void ArrayInput() { 
 String commands = 
 *input 
 some line 
 *end 
 *enter 
 *display 
 *output 
 some line 
 <P></P>"; 
 InterpretCommands(commands); 
 } 

What we remembered was that we were on the path of setting things up so the customer could type in files containing little scripts like the one in commands and there would be a generic test method that would run them all. We hadn t, as yet, figured out how to do that: we started by just writing a script as a string and making it run.

Reviewing this test, we noticed that it isn t array input, it s string input, so we renamed it:

 [Test] public void StringInput() 

Let s review what we ve done so far. This test takes a series of little commands: *input , *enter , and *output . The input command primes a TextModel with the provided input, the enter command causes the model to do its keyboard Enter action, and the output command reads the text from the TextModel and compares it to the provided output. We have written a tiny command interpreter, using just a bunch of if statements, to handle this language. I plan to come back to this topic, but just a mention here: We could have been saying here that we can t even unit test this object because the program is just a GUI program. Instead, we extracted the functional logic to a TextModel, for which we could write tests. We re not very good at C# yet, and we ll probably wind up making the connection between the Form and the TextModel better as we learn, but we got it extracted and tested with no big problems. Review Chapter 4, Extracting the Model, for that story.

Similarly, we are programming this for ourselves ”because, as you know, we are the customer ”and we could have skipped the customer tests, using unit tests instead. But we have a purpose here, which is to show you how we d write a real application, and that would include customer tests. So we wrote this simple command interpreter that supports the test StringInput, which you just saw. To save you looking back, here s that code:

 private void InterpretCommands(String commands) { 
 StringReader reader = new StringReader(commands); 
 String line = reader.ReadLine(); 
 while ( line != null) { 
 if ( line == "*enter") 
 model.Enter(); 
 if (line == "*display") 
 Console.WriteLine("display\r\n{0}\r\nend", model.TestText); 
 if (line == "*output") 
 CompareOutput(reader); 
 if (line == "*input") 
 SetInput(reader); 
 line = reader.ReadLine(); 
 } 
 } 

Not a very sophisticated or beautiful interpreter, but it works just fine. We ll see whether it needs to be improved ”later.

Lesson: Remarks on Technique

Before we move along, we d like to underline what we did. Our real purpose is to have a directory full of customer test scripts, to run them all automatically with NUnit, and to have them report results in some useful way. We could have started by finding out how to read file names from a directory and how to read lines from a file ”these are things that we don t know how to do in C# and that are necessary to the process. But we didn t do that. Why? you might ask.

We didn t do those things because, although we don t know exactly how to do them, there s clearly no big mystery. I can tell you right now what the code will look like:

 Get a list of files matching test names from some directory. 
 Loop over the list. 
 Read each file. 
 Treat it as a test 
 accept input 
 accept editor commands like Enter 
 check output, i.e. the current contents of the TextModel 

There s no mystery to the directory and file part of that, even though we don t know any of the details. The mystery is in how we ll process the file contents to do commands. Therefore, that s the part we solved first. The result was the ArrayTest. This is, we suggest, a good general rule:

The Learning Rule

When creating a new capability, work first on the part where you ll learn the most about the real shape of the problem.

There s only one problem with this rule. There s another rule that goes this way:

The Difficulty Deferral Rule

^sb Solve what you know; leave the parts you don t know until later.

Maybe later on we ll use that rule. We ll try to see if we can give some guidelines about when to do that. Right now, the learning rule seems more important.

Moving right along...