| > Many times on the production/live side of game development, gameplay and behaviors change so much that any automated testing becomes a lag on dev/iteration time, or aren't updated and stagnate as the changes happen so quickly day to day. This is especially true in iterative development during prototyping or pre/post-production, since it is mostly visual the benefits are outweighed by the speed
required to ship. So you think, you if you do testing you are overall slower ?
Skipping tests makes youufaster short term. Long term, you are slow as hell because of the lack of coverage and manual effort. Also, especially test help you with large scale changes. Because, these tell you what breaks what shouldn't have been broken. Further, test is not the same as test. In order to do efficiently testing you need to apply the test-pyramid. i.e. have lots of unittest.
less integration test.
less system tests.
less e2e tests. another guiding principle is to focus automated testing on the things are most curicial for the success of the product, or the most difficult to do manually. also, you need to chose the tools that support your testing stratgey. if you work against your tooling. oh boy, you have a journey ahead. (For example unity unittesting framework was pretty crappy last time i check -- 3 years ago ) |
Not at all long run, but in the prototyping stage it may be a hindrance or when you are going for a fun gameplay mechanic over coverage. When you lock something down then tests make sense in this scenario. You'd always want tests for unit testing data, network, core tech, but might not need it when you are building gameplay that the test is really a user experiencing it/tuning it. Even writing some rendering or gameplay tests it takes time to get them right before they are actually useful tests.
Agree on all the other items there are many levels of testing. Usually core libraries are covered, when it comes to in-progress prototyping/pre-production, it can definitely slow you down (by adding weight to changes) if it is changing constantly and not yet locked down. Another area that weighs into it is how much budget and time that the code might be in use, if it is just a tool or something that isn't needed for live code (something prototyping or to help develop it, i.e. asset packing or the like) it might not be worth it to surround it with unit/integration testing.