next »

[RecidivistSW]

How many of you are using TDD for game dev?  I've never used it and I don't see many game sample code demos that do.  It seems much bigger in web / application development.

[nikki]

I occasionaly use it -depending on the type of project-, unittests on the other hand I try to write them always when I know it's a project I will be working on longer then 1 evening.

the biggest gain unittest give you is not the testing of your units, it's the security you get with a system that tells you when stuff breaks, imagine doing big refactors without it. Its plain madness imo

you know the feeling when you have some algorithm and you have improved it and made it 5000% faster, and then how you cannot make any changes anymore without breaking the rest? and then you just don't touch it anymore. And then moss starts growing in other places. and some windows break. And you know you have to refactor anyway

[shyamguth]

TDD is heavily used in AAA game dev (with BDD being a more recent evolution of the concept). Core libraries (graphics, physics, ai...) make heavy use of tests. Regression testing in particular is very helpful, since one seemingly small change can have unexpected consequences, especially in large and complicated systems. TDD is also used in the gameplay (non-engine) part of the code for things like player and enemy movement and actions.

I don't see it as much in indie dev, probably because the code is generally smaller and the interfaces are not as well defined. Unit testing works best when you can test in isolation with particular inputs, which is usually hard to do for specialized gameplay code that requires a lot of different inputs and conditions. That being said, I still find TDD invaluable when writing libraries and modules that I plan to re-use on multiple projects.

[InfiniteStateMachine]

It's not heavily used in AAA. It's used but definitely not heavily.

I've found it useful for testing things with very expected results like a collection class but for more abstract game stuff it's borderline useless.

I've found it extremely useful in web programming and backend programming though.

[ThemsAllTook]

I use it a lot. What I've found is that it works well for core library code, but not very well game logic. What I end up doing is maintaining a large framework of back-end code that's heavily tested and gets shared between games, then build a game-specific front end on top of it with minimal automated tests for each game. Works out pretty well.

[InfiniteStateMachine]

yeah I've definitely noticed the most unit testable code tends to be the stuff you can reuse in other projects easily.

[Cheezmeister]

I love me some TDD but as others have pointed out,  it's just not well-suited to gameplay logic. It'd generally cost you more in terms of dev time than it saves in terms of bugs avoided.

I can definitely see it being useful for core logic and utils, though.

[Adam_]

I haven't used automated testing for game logic, but I'm making more and more use of it for engine features. Would still consider myself a newbie with the whole concept, but it is incredibly convenient and reduces testing time a lot. It is also a useful habit to start a bugfix by writing a test that reproduces it. As soon as the test turns green I know the bug is fixed an can rest assured that I will immediately notice in case it comes back.

So yeah, would definitely recommend for engine programming. Not sure about game logic, as it seems hard to automate to me.

[Kylotan]

Unit tests? Great idea, whenever possible. Writing a failing test as part of the bug fixing process to prevent regressions? Very sensible. But actual Test-driven design? Seems like a silly fad. Maybe it works well when you're producing software that is very "wide and shallow", ie. thousands of tiny routines that are trivial to test in isolation, and are carefully specified before implementation. But I've never met a game that worked that way, either in terms of how it was designed or how it needed to be coded.

Nor am I convinced that there's any merit in writing the tests first, or in writing code specifically to pass tests. That would seem to produce a false sense of security and takes your eye for quality off the software itself and onto the testing. Tests can only examine the inputs and outputs and won't do anything for the intrinsic quality of the functions themselves, so I'd argue that often your time is better spent on ensuring you follow best coding practices and periodically reviewing your code.

[ThemsAllTook]

Tests can only examine the inputs and outputs and won't do anything for the intrinsic quality of the functions themselves, so I'd argue that often your time is better spent on ensuring you follow best coding practices and periodically reviewing your code.

Why not both?

Writing tests first has several advantages: It forces you to design your interface without any extra implementation details in it, and it allows you to verify that each test case actually works as intended, by seeing it fail once, fixing the code, then seeing it pass. It's hard to be sure that after-the-fact tests aren't giving you false positives when they run if you've never seen them fail.

Another advantage is that once you have a test suite that fully covers the necessary inputs and outputs of an API, you can refactor the implementation to your heart's content and have immediate verification of whether the new code works or not. I've also found that interfaces I design for tests tend to be a lot cleaner and better organized than when I don't, but your mileage may vary.

[Kylotan]

Writing tests first has several advantages: It forces you to design your interface without any extra implementation details in it

That's nice, but I rarely find it's practical. Often you want to create the type of system you want to see, and observe what sort of interface naturally evolves from that. Going interface-first is fine for trivial stuff but usually with games (as opposed to REST interfaces or some other system specified from above) you neither know exactly what will be practical to expose, nor exactly what external callers are going to want to use. Half of the time you might have an abstract idea of what the API is going to be but it's not even clear which data types you're going to be returning until the work is done. So you spend double the time writing it as you're having to refactor tests as you go along.

, and it allows you to verify that each test case actually works as intended, by seeing it fail once, fixing the code, then seeing it pass. It's hard to be sure that after-the-fact tests aren't giving you false positives when they run if you've never seen them fail.

This is exactly what I was saying about how test-driven design tends to focus you more on the quality of the tests than of the software. If you fully understand your code, you can see under which circumstances the test will pass and fail. But if you don't, all you know is that you changed something which now makes that test pass. You can still get false positives if your test isn't exacting enough.

Another advantage is that once you have a test suite that fully covers the necessary inputs and outputs of an API, you can refactor the implementation to your heart's content and have immediate verification of whether the new code works or not.

I like having a good test suite where possible, for exactly this reason. But I won't write the tests first nor design the code to fit the tests. For me, that's the tail wagging the dog.

[InfiniteStateMachine]

I think it just depends on how sure you are about what you are making.

If it's a implementation of vector then you can probably write the tests first. If you were perhaps writing some kind of AI state machine then not so much. Of course at that point I might argue against writing tests at all.

I guess the value of tests could be directly proportional to how sure you are about the expected result/interface of whatever you're implementing. Which would explain why they are essentially useless for game logic.

[ThemsAllTook]

Going interface-first is fine for trivial stuff but usually with games (as opposed to REST interfaces or some other system specified from above) you neither know exactly what will be practical to expose, nor exactly what external callers are going to want to use. Half of the time you might have an abstract idea of what the API is going to be but it's not even clear which data types you're going to be returning until the work is done. So you spend double the time writing it as you're having to refactor tests as you go along.

Yep. As I mentioned above, tests don't usually work for game-specific code. As for interface-first for trivial stuff, I've found that as I gained experience, the threshold of triviality has changed... Designing interfaces is a skill that requires practice, and after doing it for a while, it gets to be a lot more intuitive.

But I won't write the tests first nor design the code to fit the tests. For me, that's the tail wagging the dog.

Designing code to fit tests definitely isn't the way to go. What I've found is that writing tests first helps me think more clearly about the design of my code in general, and makes unintended coupling stick out like a sore thumb. There's a lot to be said for the confidence you get from having a module of your code that you know is fully tested in isolation before you plug it into other parts of the overall system.

[MorleyDev]

An assumption of TDD is that if code is difficult to test there's already an issue with the design of that code. You don't design code to fit tests, instead the tests inform the design of your code.

If you have to design code to fit a test, it's possible the tests are trying to tell you "This may be poorly designed and could need a rethink". A key part of learning to do TDD is learning to 'listen to the tests' and when they're telling you about possible design flaws in your current approach. It does require a willingness to stop, back up, refactor and try a new approach.

Personally I like TDD. I find that code that is easy to test is easier to read and easier to use. So if I write the tests first, the resulting code will be easier to test from the get-go, and therefore cleaner, and also has self-proving documentation that demonstrates not only how to use that code but that it works as described. So I don't need to continually re-run the entire program continually to make sure my changes work after every line I change. Because without tests, I tend to do that.

As for tests for game logic, depends. If I'm using something like an Entity-Component System and the logic is all in-compiled-code then I find tests for game logic work pretty well, as there you well-defined inputs and outputs anyway.