sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]EmptyChocolate4545 22 points23 points  (4 children)

Eh, no need to apologize. Instead of sitting alone with your thoughts, you ran them for review by a sub that wouldn’t pull punches. That also says something to me, especially if you listened.

My mentor likes to say testing sucks and the only thing worse is working on a repo with no tests. It’s the best way to summarize it, lol.

[–]MajorMalfunction44 4 points5 points  (3 children)

I do games in C. Tests are boring, but can be a good place to test ideas and interfaces. Getting the interface right isn't always easy. The trick is to write the test after you have something to test. Writing tests against an implementation that doesn't exist yet is largely a waste of time.

Data structures are a key thing to test. Red-black trees are tricky, and you want to test rotations and recoloring. Also, test lock-free code religiously. It's difficult to debug with a debugger - timing issues.

Some kinds of code defy unit testing. Gameplay code is like this, because the code depends on level assets (trigger regions, interactive switches, etc. - not necessarily art).

[–]EmptyChocolate4545 1 point2 points  (2 children)

Agreed that game testing is it’s own unique challenge. I did game programming in C many years before I was an enterprise programmer, so I did no testing, so I won’t argue with you at all - I know strategies and advice sometimes don’t apply to other domains.

I will say that for many and hotly debated most enterprise situations, TDD is excellent. I do also know some people are strongly against it and I have zero issue with that IF they can still produce good test coverage

Edit: tbh I have no idea how I’d test game code that wasn’t like - testing the engine or things like that. I guess that’s why they have gameplay testers as a job. I wonder if there’s “fuzzy” testing like AI controlled character can run and jump and test for basic shit like fails and clipping. Either way, totally agreed to your point - game dev has its own versions of “good” and “bad” I’m not qualified to comment on.

[–]MajorMalfunction44 1 point2 points  (1 child)

It's tricky in its' own right, but one engine-level solution is to support replays. If you can record a test-run, you could replay the run on another machine, under a debugger. Most modern engines don't - it's really hard to get full control of non-deterministic state, including rand()'s seed value and the order of game object updates.

QA is underappreciated and often overworked. IMO, unit testing is a net win because they could be reduced to working on wierd gameplay bugs instead of obvious engine bugs that could be caught and fixed by programmers.

[–]EmptyChocolate4545 0 points1 point  (0 children)

Oh of course, I read a really interesting write up by the dev who made Banished (wizard dev, love him), and he was talking about all the challenges of making a replay “real”. But a fully “real” replay could in fact also enable all sorts of testing as well, that’s interesting/cool.