I think you have a misunderstanding. It's a complex topic, but here is an easy synopsis I found:
https://www.agilealliance.org/glossary/tdd/
The basic idea is that you create a specification for your application before you write it. You don't just start coding and add stuff willy-nilly as you think you might need it. You map out exactly what features are in the application (or game) and then break that down into each component or module that is necessary to support that feature. These can be classes, for example, and then break down further into individual functions. You write the specification for the input and output of each function and the expected behavior. Not code or pseudo code, but the purpose of the function. Then you write tests to ensure that the function meets it's purpose before you write the code.
After everything is connected, you can begin implementing the function, but now you know exactly how it is supposed to work and also how it should not work, and exactly what can be passed in and what cannot, and what can be returned and what cannot. And then after your first implementation in code (before you integrate it into the game) you test that the function works to some degree of satisfaction. Nothing is ever 100% bug-free, but if it passed all the tests you can be confident it is at least stable and meets the requirements.
You do this then for each additional module or function, and after all of them pass the tests by themselves, you connect them together, one by one, and make sure they work as a whole. Then finally you give them the real data (e.g. integrate it into the game) and at that point you are basically done because you have verified there are no bugs and everything should work almost perfectly. Though in practice, you cannot test for every possibility, as there are infinite, so there will still be some bugs at the end, but a very low amount or maybe none that would delay the launch.
