architecture - Is Test Driven Development viable in game development?

As being Scrum certified, I tend to prone for Agile methodologies while developping a system, and even use some canvas from the Scrum framework to manage my day-to-day work.

Besides, I am wondering whether TDD is an option in game development, if it is viable?

If I believe this GD question, TDD is not much of a use in game development.

Why are MVC & TDD not employed more in game architecture?

I come from industrial programming where big projects with big budgets need to work flawlessly, as it could result to catastrophic scenarios if the code wasn't throroughly tested inside and out.

Plus, following Scrum rules encourages meeting the due dates of your work while every single action in Scrum is time-boxed! So, I agree when in the question linked above they say to stop trying to build a system, and start writing the game. It is quite what Scrum says, try not to build the perfect system, first: make it work by the Sprint end. Then, refactor the code while working in the second Sprint if needed!

I understand that if not all departments responsible for the game development use Scrum, Scrum becomes useless. But let's consider for a moment that all the departments do use Scrum... I think that TDD would be good to write bug-free code, though you do not want to write the "perfect" system/game.

So my question is the following:

Is TDD viable in game development anyhow?

Answer

It's certainly viable, although a lot of game programmers haven't really gotten on board with the idea yet, or have a good understanding of how to test complicated systems. I admit myself that I rarely use it, except for non-gameplay-related systems that are easy to test.

Expect to use a lot of mock objects. Because of how tied together a lot of systems are, it's hard to test individual components of that.

Plus a lot of things can't be thoroughly tested. How do you test-drive, say, a particle system? How do you test that your animation system is working correctly? A lot of things are visual in nature, and aren't obvious (at least to me) as to how to do proper testing.

There are, however, a lot of things that aren't necessarily unit tests in the traditional sense of the word, but that exists as "tests" for specific features. Things like test levels for AI navigation are pretty common, but aren't necessarily the easiest things to automate.

There are certain aspects of games that can (and probably should) have unit tests written for them. Any kind of generic "file reading" system should be tested. Maybe have some tests for initialization of hardware things (3d surfaces, etc). Maybe have some mock servers and test your client/server interaction code. Things like that.