shoofle/shooflenet
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Started an article about testing of game dev.

Browse Source
This commit is contained in:
Shoofle 2013-08-23 15:49:46 -04:00
parent 3a139f5dc2
commit e1a3d6c639
1 changed files with 9 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
articles/dont_write_tests.article.html Normal file
View File

@ -0,0 +1,9 @@
<article>
<h1 class="title">Stop Writing Tests.</h1>
<p>Okay, don't do that. Tests are great. But here's my rebuttal to the worship of test-driven development:</p>
<blockquote>Test-driven development doesn't work when you're designing the overall structure of your code.</blockquote>
<p>I'm specifically thinking about this in the context of knowing - knowing! - that test-driven development is the Right Thing, but not knowing how my application is even going to be structured in the first place. I can write basic tests for collision detection structures - and I did, although not by that name, and although they were terrible and missed a massive problem - but game development. How do I write tests for a system when every few commits is radically changing the structure? Tests work well when there's an easily verified success condition which stays consistent. Writing tests can interrupt the feedback loop that is useful for exploring new concepts and approaches!</p>
<p>But on the other hand, there's still a success condition there in something like a collision detection system. I could have written a test that adds a number of objects to a world in whatever collision structure I've chosen, and then tests manually to see if they're intersecting, and then sees if the structure reports the collisions correctly. In the end I actually <strong>did</strong> do that - it wasn't tremendously automated, but I made a thing that tested collisions (and reported the speed, mostly).</p>
<p>The place it falls apart is something like the component system. The point of tests is to see whether something is operating properly. But how do you check if something is operating properly, when "properly" changes from one version to the next?</p>
<p>The broader form of this is something like the physics code. One object bouncing off another has some broadly-defined "right-feeling" characteristics, but something like that is incredibly hard - impossible? - to write a programmatic test for. For one thing, testing of live behaviors is a pain. For another, you'd have to check programmatically if it feels right. If that's possible, then please, please tell me.</p>
</article>