Test Driven Development (TDD)
Posted: Sun Apr 03, 2011 12:43 am
Have any of you guys had much exposure to Test Driven Development (TDD)?
If not you might be interested in this series of articles on TDD for games:
http://gamesfromwithin.com/stepping-thr ... ent-part-1
For those who want a quick answer, TDD is an idea that came out of extreme programming (XP), the original agile development practice. TDD is basically Agile stripped down to its most important nucleus.
To do TDD you must automatically test the code you write, famously writing the test first, an then the real game code second. People tend to get quite stuck on that part, however, so my advice is not to fixate on that. The benefit of TDD is threefold:
1. The tests force you to write the game code in a testable way, as opposed to a "detestable" way (as they say). The important side effect of this is that you end up with a more modular design and control of dependencies.
2. The code is tested. This speaks for itself! You know it works when the test passes.
3. As you modify the code over time, you are instantly alerted to any side effects that have broken existing functionality. Sometimes you may change something over here and accidently break something over there. It's a big waste of time to find out hours, days or weeks later when you no longer remember what exactly caused the change.
Before people have tried much unit testing or TDD (or any related practices) programmers are usually skeptical. They think it can't be done for systems like theirs. They are usually wrong. They think that this will slow them down. It may at first, but the point is to speed things up and when all the bug fixing time is properly counted, people with strong TDD experience believe it speeds them up, especially over the long term.
If not you might be interested in this series of articles on TDD for games:
http://gamesfromwithin.com/stepping-thr ... ent-part-1
For those who want a quick answer, TDD is an idea that came out of extreme programming (XP), the original agile development practice. TDD is basically Agile stripped down to its most important nucleus.
To do TDD you must automatically test the code you write, famously writing the test first, an then the real game code second. People tend to get quite stuck on that part, however, so my advice is not to fixate on that. The benefit of TDD is threefold:
1. The tests force you to write the game code in a testable way, as opposed to a "detestable" way (as they say). The important side effect of this is that you end up with a more modular design and control of dependencies.
2. The code is tested. This speaks for itself! You know it works when the test passes.
3. As you modify the code over time, you are instantly alerted to any side effects that have broken existing functionality. Sometimes you may change something over here and accidently break something over there. It's a big waste of time to find out hours, days or weeks later when you no longer remember what exactly caused the change.
Before people have tried much unit testing or TDD (or any related practices) programmers are usually skeptical. They think it can't be done for systems like theirs. They are usually wrong. They think that this will slow them down. It may at first, but the point is to speed things up and when all the bug fixing time is properly counted, people with strong TDD experience believe it speeds them up, especially over the long term.