Test a Lot of Files

Well, OK, now our customer can type test files and the system can run them, except that we don t want to have to write a new test like FileInput every time the customer adds a test. So we have one more test in mind: one that finds all the files and runs them. We decided that using .txt as the test file suffix was a bad idea, so we resaved the file as .test and changed the FileInput test accordingly . Then we fiddled around until we found the Directory class and we wrote this test:

 [Test] public void TestAllFiles() { 
 String[] testFiles = Directory.GetFiles("c:\data\csharp\notepad 
 \", "*.test"); 
 AssertEquals(1, testFiles.Length); 
 foreach (String testFile in testFiles) { 
 InterpretFileInput(testFile); 
 } 
 } 
 
 private void InterpretFileInput(String fileName) { 
 StreamReader stream = File.OpenText(fileName); 
 String contents = stream.ReadToEnd(); 
 stream.Close(); 
 InterpretCommands(contents); 
 } 

We worked up to this with an intermediate assert in the test, which is still shown. Since we weren t sure what would come back from the Directory.GetFiles, we asserted that it would be of length one. Sure enough it was, and we ll need to take that test out shortly. This test worked quite well, except that something odd happened .

We had originally named InterpretFileInput as TestFileInput. It made sense at the time. However, even though NUnit finds tests that have the [Test] attribute, it also finds all methods in subclasses of Assertion that start with Test . So the TestFileInput method was being run, even though I didn t intend it to be a test, and it would loop instead of throwing an exception or failing. We didn t see that it wasn t our new TestAllFiles method (can t read, I guess), and we spent a bunch of time trying to figure out why it was looping. Once we saw the problem, we just renamed the method and everything was just fine.

Lesson: What We Learned

We have a customer test! Now a non-programmer (us, the way we re doing here) can enter files named something.test and put little scripts in there, to test things. It wasn t difficult, only a couple of hours of work all together, and now with our customer hat on, we can test the system. There were only a few necessary steps:

Extract the Model

We elected to break out the functional part of the program into a separate object that is just code and no GUI. Some people talk about instantiating forms and talking to them, and maybe we ll experiment with that as well. But it seems right to break out the model anyway. You ve seen that article and we hope it seemed as natural and easy to you as it did to us.

Work Up to It

We started with that DirectInput test, which was nearly trivial. It just sent Enter to an empty TextModel and checked the output directly. That was enough to drive us to build the basic connections. The trickiest bit was the little command language. And notice how we skipped all the things that could make a command language difficult. We have no syntax to speak of, just lines that start with * and have a command word. We have no parser, just code that looks at the line to see if it is a command. A loop and some if statements.

Then we went a step further and wrote the ArrayInput test (renamed to TestInput) that worked from a string. Naturally, we were thinking we d get the string from a file some time soon. Then read one file, then read them all. Step by step, inch by inch, slowly we turned ”an empty program into a customer test.

And you can, too.