Bit of a n00b question... Do you write unit and integration tests (etc.) for your #gamedev code?

Boost for larger sample size :)

Yes, tests before code (TDD)
2.8%
Yes, tests after/during code
25.9%
No tests, no gods, no masters
71.3%
Poll ended at .
Kinda love how nobody has voted for TDD yet, not gonna lie hehe
@paintedsky So far in my limited experience gamedev is the most godless of all coding, with the exception of whatever is going on with prolog.
@paintedsky I've had strict tdd sink games (it takes too long to get to something playable, then it's too rigid to change). I still almost selected it because I tend to use tdd techniques either when a problem is too big for me to fit into my head or when I'm working on systems code (ex: math or physics).
@paintedsky I’ve tried so many times, but it adds such an overhead to development. I know for larger teams it makes a ton of sense but I’m not convinced it does for solos.

@paintedsky If I could figure out how to write automated unit tests in advance for games, I would absolutely do it.

The best I've been able to some up with are testing scripts for a human to walk through (which are better than nothing).

@paintedsky I really like this topic, because it feels like gamedevs don't test at all. And that automated unit/ integration tests are mandatory for any "real" software development. Its not :P
Really, like, for real: Testing has many levels and most game devs do a lot of system and acceptance testing, which are way more important to find economically and efficiently flaws in the "software". Sure if you write in pure C for air planes or autonomous cars, maybe than there's a different focus.
@paintedsky Don't get me wrong, semi to full automated testing here and there can be totally valid. But especially unit tests are very limited in testing complex connections of code. It's like testing only the leafs of a very heavy connected graph.
And next time you procastinate by playing your own game to long, remember you are system and acceptence testing ^^
@paintedsky It really depends on what part of the game I'm working on. It tends to be small unit tests on isolated game systems. Stuff like tests that verify my stat sheet system is doing calculations correctly.
@paintedsky I voted yes, but the real answer is, "sorta, sometimes". I think there is a (small?) subset of code that is worth writing tests for, and I make time to write tests for a subset of that. I suspect that outside of games there are more objectively correct/incorrect things, so more things worth unit testing.
@paintedsky i find it interesting that prototypes pop up in this conversation. I don't think anybody ever thought that prototypes, in any field, should be tested. They're literally code meant to be thrown away, so... xD
@RedGlow @paintedsky for gameplay code the line between prototype, heavy iteration WIP and shipped tends to be very thin, in my experience. So if I already have something that's working I can of course write tests, but this methodology is far away from doing TDD (90% of my code is written by that point) - which is why I voted "test after" (if at all)
@jonasreich yeah, it also surely depends very much on where the line is drawn for "prototype". For me a prototype is something like this (from the tumblr of Heaven's Vault): @paintedsky
@paintedsky Ain't nobody got time for that. Maybe if I would work full-time on a game with multiple people.

@paintedsky

I like how most of the people here care about "it will extend my development time!" while not thinking about "how much time I will spend to fix a random bug before the release day?"

It's also interesting that most gamedev people don't actually have a confirmation that their code works. What tools are you using to prove that your code:
- works as expected?
- works as expected after refactor/optimization?
- works as expected after plugin/engine update?

@paintedsky

I think the biggest reason why gamedev developers don't test (not even talking about TDD) - is that 90% (probably) of games made with engines, that don't provide an efficient way to write tests, and that gamedevs can't even control engine they are using

@paintedsky Uh... I always cobble together ugly test routines to prove individual bits of code are working both before I integrate them into the whole and progressively look at their interactions with other systems during development, but I'd really hesitate to call this a proper testing plan or infrastructure.
@paintedsky
My hot take is that unit test are largely only useful in predictable deterministic services. It makes sense to unit test a utility function or a service that returns data but UI's and High Level logic that has to be constantly tweaked is just adding workload to any minor change you need to make as you look for proper game feel or functionality.
@paintedsky I feel like 90% of the time unit tests are not worth doing in a game because there is just too much context to simulate before being able to do the test, it's too much of an overhead.
For indépendant modules and libraries it can still be helpful and it is probably underestimated in game development (even by me). Just need to pick the fights wisely I think.
@paintedsky Generally the best things I can do to test my game in unity are not unit tests but tools that allows me to test the game quicker: fast access to any level, debug menus to unlock stuff, the ability to start every dialog in the game to just review them all quickly, tools that check integration of specific elements in the project, build automation...
@paintedsky I try. I don't always remember, or have the energy, but the times I've done it - it paid off in big ways.
@paintedsky i really should have written tests....
@paintedsky I think if game development had better tooling for testing, I'd encourage myself to write tests. I'm a ruby/rails developer, and testing culture is very strong in theses communities with awesome tools, all my ruby code has tests, but I never tested a gdscript file
@paintedsky I haven’t figured out a good way to test code in Godot yet. In Unity I try to separate my layers out from the application so I can test the boring important things, they have a pattern called humble objects that helps. When I do that stuff I try to do TDD, but usually don’t have enough knowledge of what I want to achieve yet so I end up writing the tests after. TDD only works when you know the scope before you write the code and I find that’s rarely the case in gamedev.
@paintedsky an indie dev is lucky if he can at least finish a game. And more than doubling the development time does not help in this regard. imo tests can make sense in a work situation, not when game dev is just an hobby.