StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>TDD has become a favored approach by software developers who are serious about their profession. [<a href="http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4163026&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F52%2F4163008%2F04163026" rel="nofollow noreferrer" title="Paywall">IEEE:TDD</a>] The benefits of the approach are significant, and the costs are low by comparison. [<a href="http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd" rel="nofollow noreferrer">The Three Laws of TDD</a>]</p> <p>There are no software domains for which TDD is inappropriate, or ineffective. However, there are domains in which it is challenging. Gaming happens to be one of these.</p> <p>Actually, the challenge is not so much gaming as it is UI. The reason UI is a challenge is that you often don't know what you want the UI to look like until you've seen it. UI is one of those things that you have to fiddle with. Getting it right is a deeply iterative process that is full of twists and turns and dead ends and back alleys. Writing tests <em>first</em> for UI is likely to be both difficult and wasteful.</p> <p>Now before everybody roars off and says: "Uncle Bob says: 'Don't do TDD for UI'" let me say this. The fact that it's hard to do pure TDD for UI does not mean you can't do pure TDD for almost everything else. Much of gaming is about algorithm, and you can use TDD with those algorithms to your heart's delight. It's true, especially in gaming, that some of those algorithms are the kind of code you have to fiddle with, just like UI, and so are probably not amenable to being tested <em>first</em>. But there is a lot of other algorithmic code that can and should be written test first.</p> <p>The trick here is to follow the <a href="http://www.objectmentor.com/resources/articles/srp.pdf" rel="nofollow noreferrer">single responsibility principle (SRP)</a> and separate those kinds of code that you have to fiddle with, from those kinds that are deterministic. Don't put easy-to-test algorithms in with your UI. Don't mix your speculative code with your non-speculative code. <em>Keep the things that change for reason A separate from the things that change for reason B</em>.</p> <p>Also, keep this in mind: The fact that some code is hard to test <em>first</em>, does not mean that this code is hard to test <em>second</em>. Once you have fiddled and tweaked and gotten the code to work just the way you like, <em>then</em> you can write the tests demonstrate that the code works the way you think. (You'll be surprised at how many times you find bugs while doing this.) </p> <p>The problem with writing tests "after the fact" is that often the code is so coupled that it is hard to write the kinds of surgical tests that are most helpful. So if you are writing the kind of code that is hard to test <em>first</em>, you should take care to follow the <a href="http://www.objectmentor.com/resources/articles/dip.pdf" rel="nofollow noreferrer">dependency inversion principle (DIP)</a>, and the <a href="http://www.objectmentor.com/resources/articles/ocp.pdf" rel="nofollow noreferrer">open/closed principle</a> (OCP) in order to keep the code decoupled enough to test after the fact. </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload