A Quick Look Around

First, I ll review the code, since it has been a couple of weeks since I ve worked on this. It shouldn t take long. I ll start with the Customer Acceptance Tests. Look at them with me:

Trivial Test

 *enter 
 *output 
 <P></P> 

File Input Test

 *input 
 some line 
 *end 
 *enter 
 *output 
 some line 
 <P></P> 

Para After Para Test

 *input 
 <P></P> 
 *end 
 *enter 
 *output 
 <P></P> 
 <P></P> 

Insert Para Test

 *input 
 <P>This is the first paragraph.</P> 
 <P>This is the second paragraph.</P> 
 *end 
 *enter 
 *output 
 <P>This is the first paragraph.</P> 
 <P></P> 
 <P>This is the second paragraph.</P> 

Insert After Para Test

 *input 
 <P>This is the first paragraph.</P> 
 <P>This is the second paragraph.</P> 
 *end 
 *enter 
 *output 
 <P>This is the first paragraph.</P> 
 <P>This is the second paragraph.</P> 
 <P></P> 

These are all pretty straightforward. And it seems like it would be easy to write a few more customer tests for the sect1 story. I m thinking that it might be better to drive this whole story from its customer test, but I m afraid that might be laziness talking. It might just be a way to cheat on my Programmer Unit Tests. Let s look at some of those.

Input Command Test

There s a test for the InputCommand class. I remind myself that the InputCommand handles the customer test aspect where it starts *input and goes through *end. It takes all the lines after *input, through *end, and packs them into an object that can give back the lines without the vertical bar () that represents the cursor and that can say where the cursor should be in terms of its position from the beginning of the file. Interesting, but it probably won t be affected by what we re doing.

ITestTextBox and MockTextBox

These classes were built to let me test that irritating problem where the cursor wasn t visible. Again, that probably won t affect us here.

Test Text Model

Now this looks interesting. This is the class that tests all the text manipulation that goes on in the TextModel. Surely we re going to have to add to TextModel to do the insertion of the sect1 tag. Let s look at these tests:

 using System; 
 using System.Collections; 
 using NUnit.Framework; 
 namespace Notepad { 
 [TestFixture] public class TestTextModel : Assertion { 
 private TextModel model; 
 [SetUp] public void CreateModel() { 
 model = new TextModel(); 
 } 
 [Test] public void TestNoLines() { 
 model.SetLines(new String[0]); 
 AssertEquals(0, model.Lines.Count); 
 } 
 [Test] public void TestNoProcessing() { 
 model.SetLines(new String[3] { "hi", "there", "chet"}); 
 AssertEquals(3, model.Lines.Count); 
 } 
 [Test] public void TestOneEnter() { 
 model.SetLines(new String[1] {"hello world" }); 
 model.SelectionStart = 5; 
 model.InsertParagraphTag(); 
 AssertEquals(3, model.Lines.Count); 
 AssertEquals(18, model.SelectionStart); 
 } 
 [Test] public void TestEmptyText() { 
 model.Lines = new ArrayList(new String[0]); 
 model.InsertParagraphTag(); 
 AssertEquals(1, model.Lines.Count); 
 AssertEquals(3, model.SelectionStart); 
 }     [Test] public void InsertWithCursorAtLineStart () { 
 model.Lines = new ArrayList(new String[3] { "<P>one</P>", "", 
 "<P>two</P>"}); 
 model.SelectionStart = 14; 
 model.InsertParagraphTag(); 
 AssertEquals("<P>two</P>", model.Lines[2]); 
 } 
 [Test] public void TestLineContainingCursorDirectly() { 
 // todo? 
 } 
 
 [Test] public void ControlTwo() { 
 model.SetLines(new String[1] {"<P>The Heading</P>" }); 
 model.ChangeToH2(); 
 AssertEquals("<H2>The Heading</H2>", model.Lines[0]); 
 } 
 } 
 } 

Browsing that, I see that there s a todo test, something about testing a line directly that contains the cursor. The intention was to remind myself (and Chet?) of a test that we might want to write, but in fact, now I can t remember what was meant . This wasn t enough of a clue. Little lesson learned here about documenting ideas a bit better. I think I d still do it right here in the code, but longer comments about what was needed might have helped me remember. For now I ll ignore it and I ll leave the test there in case I can get together with Chet later. He might remember, or chatting about it might help.

Lesson  

One of my editors commented that the test should be refactored out. He s probably correct. But the fact is, I left it here, useless, hoping that it would remind me of something. But it never did. I m not sure whether to advise you not to do this, to write better comments, or what.

As we work, there are so many ideas that we get. Many of them are good, but we just can t do them all. Sometimes something pops into our mind and we don t want to forget it, so we re inclined to write it down. Yet, months or years later, we have perforce had to pass over most of those ideas. My practice has been to write them on cards sometimes, or to write them in a notebook that I carry, or to write them into the code or document I m working on. None of these approaches works perfectly , but I think that the closer the idea is to where I might next need it, the better. So I leave code ideas in the code. It s not perfect, but it s the balance I ve chosen .

There s also that test, ControlTwo(), that we haven t talked about. It s supporting some experimental code that changes the tag of the current line from P to H2. There s this test, a customer test, and model support. I didn t talk about it in the narrative because there was no particular lesson to be drawn. We ll be using it shortly as a prototype for another test, however.

Looking at these tests, we can see that we could produce Programmer Unit Tests for the sect1 idea. It would be easier to use Customer Acceptance Tests, because with the programmer tests we seem to have to do a lot of counting and such.

Here s what I m going to do. These tests are a lot harder to write than the customer ones. We learned a lot doing the customer ones, and that learning hasn t shown up here yet. So I m going to write a customer test and see that it doesn t work. Then, using that test as a model, I ll write some programmer tests, but I m going to focus not just on the testing but also on improving the testing. Let s see what happens.