Original post by return0
For all of you advocating globals or singletons, how the hell do you test your code to verify it actually works? How do you write isolated unit tests to check your design makes sense before committing to writing the whole subsystem, and to prevent regressions?
Writing non-shit tests requires being able to check the behaviour of components in specific, isolated contexts, and that requires the ability to mock your collaborators and dependencies; you cannot do that if you are using globals/singletons. You'd have to spin up and configure other full systems, accessed through the global (and roll back this state after every test) - sounds horrid!
It's so much easier just to ask for abstractions for your dependencies. You can create mock implementations in whatever state you want and testing is easy, and you also get a loosely coupled (and generally more cohesive) design.
I have no idea what you just said. Is this related to game development in any way at all?
I have several silly results a day as I just type shit in and see if it worked and it doesn't. But none of these takes >3 seconds of typing to fix and none of them ever causes a long term problem that a colleague couldn't figure out in about 3 seconds again.
If we ever ran into these notional problems that advocates dream up, then we'd probably re-examine our working practices. However they just don't. So we get on with churning out perfectly fine working code and f**k the standards comittees and globals police.
How the hell did we get into a situation where lots of otherwise bright and technical people think that leaving a global variable open to abuse is somehow dangerous and a sin and worthy of a bloody flame war.
And just to finish off, what the hell is a unit test anyway? (rhetorical) I think I can guess and it sounds an awfully tedious way to avoid getting work done to me. If anyone asked me what our unit testing practices were in an interview, the very next thing to happen is me saying "thanks for your time" and handing him his train fare. We don't write unit tests, we write games.
Well, flame on then I guess. I could do with losing another one through sheer weight of numbers, as it makes my future as a game programmer feel ever more safe.