Late last year my company provided our IT team with a weeks training in Object Orientated programming and design. Much of the course was taken up with UML and methodologies but the final day was more focused on actual programming concepts (which I enjoyed the most). The tutor was a really nice guy and was happy to answer any questions (I guess at a £1,000 a day, I'd answer anybody's questions). As our IT department is relatively small (4 members) the tutor advised us to follow the
SCRUM methodology which is a variation on Extreme Programming (XP) and has thus far helped us be more productive than we have normally managed.
He also mentioned a discipline known as Test Driven Development (TDD) which I had never heard of before and as he explained is the practice of writing tests before writing any code and then making those tests succeed. Now, unless you are aware of this methodology, I would expect the same response as I had, "How can you write a test for something that doesn't exist?".
Well, I have recently been thinking about this principle and done a little research and I can really see the benefits. The basic idea is that you write a test using xUnit (NUnit for VB.NET, JUnit for Java, pyUnit for Python and so on) and run that test. This test will then fail (red bar) as there is no code to test. More likely than not however, the code won't even compile as there is no code for the test to run. So to get around this, you create the object that you are testing and add stubs (empty procedures) in order for your code to compile and then watch it fail. Then you go back to the object and have it return what your test expects it to return (in the first phases, this would be simply hardcoding the values to make the test succeed) and run it again, this time it should succeed (green bar). Then you start to refactor your object so that it starts to look more like a piece of production code rather than a slap happy coder having a laugh! All the time, testing to make sure that each set of changes has not broken the initial test.
Now the thing I really like about this approach is that you can write your initial test that uses a non-existant object and enforce some assumptions on how you would like this non-existant object to expose it's interface. This then gives you a really good outline when it comes to actually creating the object and making those tests succeed. Of even more importance is that when an object has to be changed for whatever reason, you have the tests to rely on that will tell you if you have broken anything by implementing those changes.
So now having done some research on this (links at the bottom for anybody interested), I went ahead and downloaded NUnit as I will be using .NET (still trying to learn C# proficiently so may go ahead with that) and also bought a book Test-Driven Development By Example by Kent Beck. Now I'm armed and ready, I just hope I don't have nightmares about red bars (rather nice dreams about green bars ;))
TDD Links I found of interest