Some Additional Tests

Let s summarize some additional tests that we wrote. We ll review the code that supports them later on.

We implemented a new feature that handled the special case of hitting Enter in a TextBox containing nothing. It just inserts a single paragraph tag pair (not the blank line). Here s the test we wrote for that:

 [Test] public void TestEmptyText() { 
 model.Lines = new String[0]; 
 model.InsertParagraphTag(); 
 AssertEquals(1, model.Lines.Length); 
 AssertEquals(3, model.SelectionStart); 
 } 

This test didn t work, because it was a new feature, and it took us a little while to make it go, because we had a subtle defect in our code that figures out which line the selection is on. It turns out that if the cursor was at the beginning of a line, our code thought it was in the previous line. There were a couple of offsetting errors making that happen, and it took us some time to find the second problem.

To show this bug and make sure it was fixed, we wrote another test, to handle the cursor being at the start of the line. It looks like this:

 [Test] public void InsertWithCursorAtLineStart () { 
 model.Lines = new String[3] { "<P>one</P>", "", "<P>two</P>"}; 
 model.SelectionStart = 14; 
 model.InsertParagraphTag(); 
 AssertEquals("<P>two</P>", model.Lines[2]); 
 } 

In this test, the cursor is ahead of the P tag on line two. We had discovered while working on the previous test that when we hit Enter there, the blank line and paragraph tag pair was inserted in front of the two line, instead of after it as we expected. So we wrote this test in preparation for fixing the problem.

Lesson  

^sb Find a bug ”write a test. This is a standard Extreme Programming recommendation: if you find a defect, first write a test that will work when the defect is fixed, and only then fix the defect. This idea has at least three advantages:

• It helps focus our attention on the exact circumstances that cause the problem.

• It gives us a clear indication when we have it fixed.

• It subtly teaches us a little about how to test better and where our mistakes tend to be.

I think it s the last advantage that really makes the recommendation worthwhile. By having the discipline to write this test and fix it, we have a sharper focus on what kinds of situations we make mistakes in and on the kind of test we should write to avoid those mistakes. We always try to reflect just a bit ” What have we learned from this? ”but even if we forget, this little ritual pounds a little sense into our heads. Try the practice out ”we think you ll like it.

This test gave us a bit of an extra problem: when I originally counted the characters to figure out where the selection start should be, I got 13. So we thought the code was wrong, changed it back to the way it had been before the TestEmptyText, and then finally figured out that our test was wrong by printing the output and counting it again.

Still, all this rigmarole took us only about an hour , and now we feel that the TextModel is pretty well protected for further refactoring to express its ideas better. Now we can get back to it.