[zamalek]

This is my impression too. There's also good reasoning: TDD is poorly suited to the industry.

For example, how would you test your renderer? Do you run the pipeline and check it against a final image? No, strict TDD would require that the asserted image be hand-crafted. Do you check that each part of the pipeline works as a unit? You can't without running shaders on the GPU (requiring the previous image test).

What game developers are slowly starting to master (already far more than anyone else) is integration testing. Instead of requiring detailed repro steps, just record the testing session in extreme detail and replay it - if anything goes wrong this can be turned into an automated test case.

There are no golden hammers and that includes TDD. TDD is an amazing solution that can provide value in 99.99% of scenarios. We should be scrutinizing areas where it doesn't add value; there is interesting stuff going on there.

[discreteevent]

In my opinion it's the integration tests that provide 99.99% of the value in 99.99% of the cases. Maybe not full integration tests (which can be expensive to run) but at least subsystem tests. These are the ones that find the real bugs. A very high percentage of unit tests once passing tend to continue to pass and only fail when you intentionally change the implementation. i.e. they impede your progress. Low level unit tests are very good for testing an algorithm or something like a parser, say, but that's not a high percentage of the code on the systems that I have worked on.

[andybak]

That matches my intuition. The espousal of unit testing vs other types of tests as "the one true way" actually impeded my adoption of testing in general as I couldn't wrap my head around how to approach it without suffering a huge productivity hit. I thought it was just me "not getting it" but I sense the pendulum is beginning to reverse direction.

[StavrosK]

I agree, this matches my experience. I find that many bugs can crop up in the interface, which is something that TDD inherently doesn't catch, whereas integration testing will both catch bugs in the interface and the units themselves.

[ajeet_dhaliwal]

Exactly my experience too. I have been an automation developer in three teams across two games companies - integration tests provide great value if run continuously and daily, they are especially helpful for uncovering regression. Also the parent describing the sad state of affairs in the AAA games industry is fairly accurate and that leaves little hope for TDD/BDD and other similar practices. One of the sources of all of these problems are business model challenges at a company level which then leads to low pay and high stress creating high attrition. Things just aren't planned out the way you may think they would be. The toss away tradition means that unlike companies developing long running services where automated tests written once may be valuable for even a DECADE, that's not true in games so the ROI isn't quite as high, although this may be changing slightly at least when it comes to engine churn and so in does appear to be slowing down.

Aside - having worked on automated testing in the AAA games industry I have found that good reporting helped managers and other devs better see the ROI from the work put in and I have been involved in creating a service for reporting automated test results across dev teams, see my profile if you're interested and give it a try, you can use it for free and I'd love to get your feedback - send me an email.

[quadcore]

I agree with that.

[Rannath]

You don't test your renderer. The renderer is third party tech in 99% of games. You test that the right calls are being made to the renderer. For that you use a mock. Your test are there to assert correctness in YOUR code. if something exists outside your code you test it another way.

Example: Sam is writing an engine. He has OpenGL, DX9, and DX11 bindings. He also has a Mock that logs calls and checks to see that they match known good logs. Sam then sets up a demo to cycle through all the different graphical capabilities of his engine, this also gives Sam the ability to test his AI/scene crafting code.

[bitwize]

> For example, how would you test your renderer?

Oh, that's easy.

    npm install --save-dev mock-opengl

[bjpbakker]

Mock testing your rendering only assets that you call the methods you expect in your tests. It does not assert rendering in any way.