3 ms·

I am not convinced this is always true. The first 25 years of my career was spent making games. Never had tests. We had testers but no tests. I then worked at a

I am not convinced this is always true. The first 25 years of my career was spent making games. Never had tests. We had testers but no tests. I then worked at a big company with tests. My first experience with them. Working on something important I loved them but they easily cut my velocity by 70% compared to what I used to get when working on games. The games were AAA and shipped to millions of customers on CDs and Cartridges so no bug fixes allowed after the fact. Being a big company and big project there were 10-30 engineers who's maintained testing infrastructure, continuous integration, etc. That's larger than the entire engineering team on most games I worked on. I'm not arguing against tests and having had the experience of testing I'd use them when appropriate I'm just not sure the exact cutoff. If I was working on a game engine for multiple teams I'd be writing tests for sure. If I was working on a small 5-20 person team with custom tech I'm not sure I'd start adding tests where I didn't before. Maybe if there was IAP or multi-player online or some other server component and metrics. Or maybe if it was easier to get started and maintained. Theres a bunch of big differences with games vs much other software. Often games are not maintained after shipping. Of course that's less true today than it was in the past with longer term online games but it's still also true that many games area pretty much done the moment they ship. Another big difference is the teams are 70-90% non-engineers making tons and tons of data. I mostly bring this up as that often software engineers talk past each other since no all software engineering is the same. https://www.joelonsoftware.com/2002/05/06/five-worlds/ https://www.joelonsoftware.com/2002/05/06/five-worlds/

djd20 8y ago
I think the key distinction there is - you'd ship the games, and never change them again. What the tests do is let you continually evolve the software over a long period of time. What you need tests for is to give you confidence that chaning system a doesn't impact system b negatively, allowing the software to continue evolving at a much faster pace once you have a good test suite in place.
heavenlyblue 8y ago
Well, I mainly work in a team where developers ship separate products for the internal usage. So it's not really working in a team. Products are generally quite technical - it's not your usual CRUD shop. I do write tests, but only post-factum, when I know for sure this component will be re-used in other components. I write them in cases where I know I will forget about the certain edge-cases in some time, so changing the code will most certainly introduce bugs. When you have components that are reused over the course of several years (and obviously being optimised if the requirement is there), the chance of regressions is severely increased. So I see that "writing tests for everything" is more of a political stance, rather than entirely practical.
bluGill 8y ago
Anytime you are writing a product where the first version you ship will be the last manual testing is going to be cheaper/faster than automated testing. Only when you are making changes over several years do automated tests really pay off (in a few cases this can be some core libraries to a product that otherwise is ship and forget).

djd20 8y ago

I think the key distinction there is - you'd ship the games, and never change them again. What the tests do is let you continually evolve the software over a long period of time. What you need tests for is to give you confidence that chaning system a doesn't impact system b negatively, allowing the software to continue evolving at a much faster pace once you have a good test suite in place.

heavenlyblue 8y ago

Well, I mainly work in a team where developers ship separate products for the internal usage. So it's not really working in a team. Products are generally quite technical - it's not your usual CRUD shop. I do write tests, but only post-factum, when I know for sure this component will be re-used in other components. I write them in cases where I know I will forget about the certain edge-cases in some time, so changing the code will most certainly introduce bugs. When you have components that are reused over the course of several years (and obviously being optimised if the requirement is there), the chance of regressions is severely increased. So I see that "writing tests for everything" is more of a political stance, rather than entirely practical.

bluGill 8y ago

Anytime you are writing a product where the first version you ship will be the last manual testing is going to be cheaper/faster than automated testing. Only when you are making changes over several years do automated tests really pay off (in a few cases this can be some core libraries to a product that otherwise is ship and forget).