4 ms·

Game Development is test driven...When they play the part they just coded, isn't that testing?

by phsr 17y ago

daredevildave 17y ago
Not quite the same thing, you are talking about QAing the product. Test driven development or more simply unit testing code, is writing automated tests that ensure your code at the smallest unit you can access ( e.g. a single method ) is doing what you expect under all conditions. See: http://en.wikipedia.org/wiki/Test-driven_development http://en.wikipedia.org/wiki/Test-driven_development and: http://en.wikipedia.org/wiki/Unit_test http://en.wikipedia.org/wiki/Unit_test
bendotc 17y ago
That's barely even testing, and it's certainly not TDD. If I play through the feature I just coded or the bug I just fixed, I can verify that it's doing what I think it's doing, but I need outside verification that it's correct. In effect, I can verify my code's precision (it's doing precisely what I told it to do), but not it's accuracy (if my idea of a feature is inaccurate, my own testing won't catch that). That having been said, TDD and automated testing can definitely make some headway into game development, but there are a whole host of challenges and questions to surmount there, especially for code-bases that are going to get stripped down to bare-bones every 1-3 years for a new game, if they get reused at all, so the tolerance for hacky code is quite a bit higher.
derefr 17y ago
I don't think you understand the significance of the word "driven." Coding something and then testing it is not TDD. In TDD, you don't write any application code that a failed test doesn't demand in order to pass—and even then, only just enough to make that test pass, even if it just means alwars returning 4 from a rand function. Of course, a "play test" is not an unit test, or an integration test (and is only mildly similar to an acceptance test.) Playtest-driven development would be an entirely new affair, likely involving gameplay freeze-states and kept in version control, and a constant numerical analysis for the player's emotional state (perhaps using some sort of face-recognition) given alternate code paths.

Game Development is test driven...When they play the part they just coded, isn't that testing?

by phsr 17y ago

Game Development is test driven...When they play the part they just coded, isn't that testing?

Not quite the same thing, you are talking about QAing the product. Test driven development or more simply unit testing code, is writing automated tests that ensure your code at the smallest unit you can access ( e.g. a single method ) is doing what you expect under all conditions. See: http://en.wikipedia.org/wiki/Test-driven_development http://en.wikipedia.org/wiki/Test-driven_development and: http://en.wikipedia.org/wiki/Unit_test http://en.wikipedia.org/wiki/Unit_test

bendotc 17y ago

That's barely even testing, and it's certainly not TDD. If I play through the feature I just coded or the bug I just fixed, I can verify that it's doing what I think it's doing, but I need outside verification that it's correct. In effect, I can verify my code's precision (it's doing precisely what I told it to do), but not it's accuracy (if my idea of a feature is inaccurate, my own testing won't catch that). That having been said, TDD and automated testing can definitely make some headway into game development, but there are a whole host of challenges and questions to surmount there, especially for code-bases that are going to get stripped down to bare-bones every 1-3 years for a new game, if they get reused at all, so the tolerance for hacky code is quite a bit higher.

derefr 17y ago

I don't think you understand the significance of the word "driven." Coding something and then testing it is not TDD. In TDD, you don't write any application code that a failed test doesn't demand in order to pass—and even then, only just enough to make that test pass, even if it just means alwars returning 4 from a rand function. Of course, a "play test" is not an unit test, or an integration test (and is only mildly similar to an acceptance test.) Playtest-driven development would be an entirely new affair, likely involving gameplay freeze-states and kept in version control, and a constant numerical analysis for the player's emotional state (perhaps using some sort of face-recognition) given alternate code paths.