It's amazing what you can do with a PC these days. It seems all you need to buy in the way of music hardware is a MIDI keyboard.
Free software from Psycle
16 April 2005
Personal Web sites
The Personal Web Site Starter Kit is a Microsoft tool for creating personal websites.
More testing tools
Fit is a tool for unit testing. It can be used collaboratively to create user acceptance tests. The results appear as a web page. Fit was created by WardCunningham. It is free to download.
TestDriven.net is a tool for unit testing that integrates with the Visual Studio IDE. I've downloaded it and will be trying it out.
TestDriven.net is a tool for unit testing that integrates with the Visual Studio IDE. I've downloaded it and will be trying it out.
13 April 2005
TDD continued
Now my new calculator is working I have 18 tests and they all pass. I have deliberately not thought about the design too much.
There is quite a bit of duplication in the code. I'm tidying it up. It's almost refactoring, but as there is only one little class, really it's just reviewing the software as a whole. Up till now I'd been looking at just the functionality I was adding to satisfy each new test. This lead to a working program, but not one that I'd be proud to display.
To start with I moved any common code into new methods and then recompiled and ran my tests. Occasionally this warned me that I was introducing a bug and I was able to roll back and see that indeed the tests were right and it was not quite common code after all.
Then I reviewed the names I'd used. Some of them were pretty vague so I gave each method property or variable a meaningful name. The tests confirmed everything still worked.
What I plan to do now is to work on something else for a week or so, then come back to this project and try to add some more functionality. Perhaps I'll add some memory keys. The idea is that the tests should make it easy to continue development.
I added some comments as I was coding, but now I have removed these. The theory is that you don't need comments if you have unit tests and readable code. We shall see...
There is quite a bit of duplication in the code. I'm tidying it up. It's almost refactoring, but as there is only one little class, really it's just reviewing the software as a whole. Up till now I'd been looking at just the functionality I was adding to satisfy each new test. This lead to a working program, but not one that I'd be proud to display.
To start with I moved any common code into new methods and then recompiled and ran my tests. Occasionally this warned me that I was introducing a bug and I was able to roll back and see that indeed the tests were right and it was not quite common code after all.
Then I reviewed the names I'd used. Some of them were pretty vague so I gave each method property or variable a meaningful name. The tests confirmed everything still worked.
What I plan to do now is to work on something else for a week or so, then come back to this project and try to add some more functionality. Perhaps I'll add some memory keys. The idea is that the tests should make it easy to continue development.
I added some comments as I was coding, but now I have removed these. The theory is that you don't need comments if you have unit tests and readable code. We shall see...
12 April 2005
Unit Testing Notes
The continuing story of my attempts at Test Driven Development...
I'm now writing a GUI application, a simple calculator. Windows needs a new calculator.
I've structured the application so that all the logic is in a calculator.dll file, the GUI only handles input and output, just as it should. This means I can have a separate test class to test the logic of my calculator.dll. I've used some modified sample code to add an array of buttons to the calculator form dynamically when it loads. This is in a buttonarray.cs file, which I'm not testing as it is part of the GUI.
After years of writing code first and then (maybe) writing tests a lot later, it is a very difficult habit to work against. This time I forced myself to write a unit test first, test it to see that result was red, and then start writing code to turn it green.
The first few tests felt really odd; it was a bit like trying drive somewhere using only reverse gear. Once I had about 10 tests done, and had run out of short term memory to recall exactly what they were, it started to feel more sensible to add another test as a way of starting on the next bit of the problem.
I deliberately didn't spend any time on restructuring or refactorinng the code, I took the approach that if it passed the test then it was complete.
It is true, each time you run the tests and the result is green, it does begin to give you more confidence that the latest change hasn't broken anything. And, when I did break the code trying to handle a particular condition, I was able to roll back a bit and start again.
This does mean that you really can focus on just the problem at hand, the new tiny bit of functionality you are trying to add, because you don't need to worry about breaking anything. If you break it, you will know. It feels a lot safer changing the code, when your tests are automated. It only takes seconds to run all those tests again.
I can see unit tests have some real benefits, so far I am not sure about some of the other claimed benefits.
I'm now writing a GUI application, a simple calculator. Windows needs a new calculator.
I've structured the application so that all the logic is in a calculator.dll file, the GUI only handles input and output, just as it should. This means I can have a separate test class to test the logic of my calculator.dll. I've used some modified sample code to add an array of buttons to the calculator form dynamically when it loads. This is in a buttonarray.cs file, which I'm not testing as it is part of the GUI.
After years of writing code first and then (maybe) writing tests a lot later, it is a very difficult habit to work against. This time I forced myself to write a unit test first, test it to see that result was red, and then start writing code to turn it green.
The first few tests felt really odd; it was a bit like trying drive somewhere using only reverse gear. Once I had about 10 tests done, and had run out of short term memory to recall exactly what they were, it started to feel more sensible to add another test as a way of starting on the next bit of the problem.
I deliberately didn't spend any time on restructuring or refactorinng the code, I took the approach that if it passed the test then it was complete.
It is true, each time you run the tests and the result is green, it does begin to give you more confidence that the latest change hasn't broken anything. And, when I did break the code trying to handle a particular condition, I was able to roll back a bit and start again.
This does mean that you really can focus on just the problem at hand, the new tiny bit of functionality you are trying to add, because you don't need to worry about breaking anything. If you break it, you will know. It feels a lot safer changing the code, when your tests are automated. It only takes seconds to run all those tests again.
I can see unit tests have some real benefits, so far I am not sure about some of the other claimed benefits.
Subscribe to:
Posts (Atom)