Well, I had my very first blog mishap early this morning. I had written a very lengthy discussion of the merits of TDD (Test-Driven Development) for all programmers. I was, in fact, quite pleased with my efforts, so upon seeing that it wouldn't publish for some reason, I was quite disappointed. Anyhow, I ended up deleteing it because I thought I had copied it to the clipboard. Not so. I think I shall try to re-create the magic that was birthed early this morning.
What is TDD?
TDD, or Test-Driven Development is the process of writing a set of tests to test the functionality of a program, before you have written it! So, at uni we do all our programming in Java, and we have a nice little automated testing framework called JUnit (yes, that joke has been made many, many times), and we effectively define how our program should behave by writing the tests, and when we are convinced that our test suite is thorough, we go ahead and write the code that will pass all of those test.
So whats the point?
Well, we're told that the advantages are that we will end up writing less code overall, because we have very tightly specified what our program should do. On top of that, we get instant feedback on which parts of our code are correct, and which aren't, so when it comes to tracking down errors we know exactly where they occur, and have to spend less time in the debugger. So the thoery is that we write less code, and spend less time fixing code, so despite the time it takes to write the tests, we still end up faster.
So why wouldn't everybody use it?
Well, what they casually drop in, is that trying to use TDD when you're writing graphical interfaces can be diabolical. So, immediately most of the class switches off. We all want to play with OpenGl and SWT, the cool stuff, what use is TDD going to be to us? It has recently become apparent to me that if you program properly, and clearly separate your interface and application layers (ie the guts and the eye-candy), then it should be possible to use TDD for almost anything. For instance, at uni we did an exercise where we wrote a screensaver. Now, to test-drive the development of this program we decided to put all the drawing functionality into its own type, called a "painter". In order to actually use the tests we made two painters, one which painted graphically, and the other which logged changes to the scene. We could then run our tests on the mockup painter to make sure that the underlying code which manipulated the objects was working, and then switch over the the graphical painter as the last step.
I wish I had known about TDD when I embarked on my journey towards creating an e-commerce package. I certainly would have benefitted from having to plan all of the functionality, and work through the tests, one by one, writing code to make them pass, I would definitely have saved me a lot of time wasted through wondering "what next?". But on the other hand, a friend of mine who is writing a 3D rendering engine thinks TDD is useless, and I guess he has a point, a rendering engine is all about the code that does the drawing, and it would be difficult indeed to test-drive.
However, I don't think you can throw out a technique because it is not so useful in one small sector of a discipline. Because even in the wider spectrum of games programming (as opposed to renderers) TDD could be used to test the physics and gameplay, (log actions instead of passing them through the renderer) and thus, could speed up the development of games overall.
I do a fair bit of web-based development work, and again this is fairly interface heavy, good luck TDD'ing a web-page. I wonder, how effective TDD would be for me. Sure, as I mentioned earlier, it would help me to organise my workflow, and in the few occasions where I get nasty problems in my PHP code, it would probably help me sort them out, but I tend to spend most of my time making html pages render the same in MSIE and Mozilla Firefox (there is a standards body for a reason people!).
I would be interested to see how much my development time could have been shortened, as I near a release candidate stage, and my man-hours are reaching about 50 on this project (I know, its strange, if I was doing this full time I would have been finished a couple of montsh ago). My next project will probably be to refactor this e-commerce package (that isn't quite finished yet) and put in a whole bunch of stuff that I keep thinking about, and see if I can make more money out of it, and I think I might introduce some TDD. I'm also going to overhaul the blog package that I have created sometime, and see if I can make some money out of that (tt probably won't happen though, when you can blog for free here at www.blogger.com), and it could be a candidate for TDD as I have to re-write the interface layer entirely and add some features to the application layer as well.
So, I kinda like TDD, and I am quite interested in the wider eXtreme Programming arena. I'll keep you posted as I learn more.
Thankyou and goodnight!
Thursday, September 01, 2005
Subscribe to:
Post Comments (Atom)
2 comments:
Yea, I've definatly learnt to apply TDD alot better, and I'm not throwing it out as a technique (after all, I do still have to learn it weather I like it or not - so i might as well try to like it) But i'm just finding it hard to apply it anywhere usfull in the core rendering engine.
Yeah well fair enough, there probably wouldn't be a net time-gain in trying to TDD your rendering of complex shaders, because, assuming its possible it would be incredibly complex.
Post a Comment