Smaller Details

We ve covered the big things we noticed, either fixing them or deciding consciously not to fix them yet. Now for some small things:

CommandTest

We look back at Command Test. The InterpretCommand method has a bunch of if statements in it. These should at least be if/else, shouldn t they? The code isn t very good, but we think it s clear enough and we decide to let it lay:

 private void InterpretCommands(String commands, String message) { 
 StringReader reader = new StringReader(commands); 
 String line = reader.ReadLine(); 
 CreateModel(); 
 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, message); 
 if (line == "*input") 
 SetInput(reader); 
 line = reader.ReadLine(); 
 } 
 } 

TextModel Method: TestText

The TextModel object has a method named TestText that s there only for testing. It looks like this:

 public String TestText { 
 get { 
 StringBuilder b = new StringBuilder(); 
 foreach(String s in lines) { 
 b.Append(s); 
 b.Append(System.Environment.NewLine); 
 } 
 b.Insert(SelectionStart,""); 
 return b.ToString(); 
 } 
 } 

Some people would wonder about having a test method there at all or whether it should be public or private or what. We don t worry about it. We needed a test method that allowed our customer to compare the TextModel s state with what s expected. Possibly that method could be on some other object, but we decide it s not doing any harm where it is. We ll keep an eye on it.

Comments

We have a few comments in TextModel. We make a note to go over those and determine whether the code can be cleaned up to make them unnecessary.

LinesAfterCursor and LinesThroughCursor

The method LinesAfterCursor in TextModel isn t used any more. We check with Visual Studio References, compile, and test. Everything works. Same for the method LinesThroughCursor: check with Visual Studio, compile, test. Everything is OK.

Lessons

Here are a few lessons we learned today that I d like to pass on to you:

Delete It

Somewhere along the way ”I don t even remember where ”those methods became useless. Maybe they were always useless. We noticed, removed them, tested , and let them fall into the bit bucket. This is, I suggest, usually your best practice: if it s not used, delete it. The methods are there in the code manager, in case we ever need them. And we write simple, clear code, so they ll be easy to write again if we have to. So get em outta there, that s my advice.

No GUI Testing

We haven t even run the GUI for a couple of days! We so completely trust our CustomerTests that we haven t had the slightest temptation to run the GUI. This is a miracle , and we ll come back to it in the next chapter.

Reflection on Watts s Ideas

We still aren t desk-checking our code. All day today, however, we had only one compile error (the missing parens on Close) and one test error (the Close itself), so if desk-checking were to help us today, it would have had to find errors not found by our unit tests or our customer tests. We ll keep watching for bugs that show up as we use the program, when we get around to actually using it. For now, we re not seeing where the benefit could be.

In fairness to Watts s ideas, though, we wouldn t expect to see them. His suggestion is that in desk-checking we ll find bugs that (at least) the compiler won t find and (possibly) that our tests won t find either. We had only one case where our tests found anything, and desk-checking wouldn t have helped that and would have taken longer if it had, because compiling and running takes...wait a minute, I ll do it...six seconds. Hard to beat that with the human brain. But we ll keep paying attention to errors and see what happens.