3 ms·
> but for 90% of projects, automated testing is the most efficient long term strategy I don't think this is a good way to think about it. I see plenty of pro
by olau 8y ago
> but for 90% of projects, automated testing is the most efficient long term strategy
I don't think this is a good way to think about it.
I see plenty of projects that don't go anywhere, and I also see plenty of projects that do go somewhere, but where large parts change so little and are so easy to test manually that there's little point in much automation. Other parts are complex and full of contradictory business rules so formal tests are necessary.
Of course, YMMV. If you're inside Google, things are probably looking very different. But most people aren't.
- bunderbunder 8y agoI've inherited one or two projects like the first one you describe before, and, when they don't have tests, it's awful. The problem is, regardless of how stable the code was, or how easy it was for the original author to test it manually, if the code hasn't been worked on for ages, then the original author is either gone or can't remember all the details of how it was supposed to work anymore. Which leaves you in a dangerous situation, because there's no good way of knowing which behaviors are by design and which ones are incidental.
- gnahckire 8y agoAdding in to your point, it's really easy to get familiar with a codebase and be confident that there are no regressions when you make changes if there are comprehensive tests. Similarly, tests can serve as a device for asserting contributions are acceptable pre/post-merge as well as evaluating that your dependencies work as expected.
- drdeadringer 8y agoDocumentation. I swear, if it's not "we don't have time to test" it's "we don't have time to document". Ok, but you've hired all these firefighters instead.
- bunderbunder 8y agohttp://wiki.c2.com/?SharpenTheSaw http://wiki.c2.com/?SharpenTheSaw
- TeMPOraL 8y agoAlso, if you've inherited code, or didn't work on it for couple weeks, chances are you won't know/remember how to do the manual tests, and will waste time trying to rederive it from first principles. This also applies to any other kind of "ad-hoc" ops, and multiple times more so if the activity involves multiple runtimes - e.g. issuing a shell command. I've learned this the hard way, and these days I note down the precise steps/commands for any manual op that's not very clearly a one-time thing / throwaway. Your future self and whoever inherits your code will both thank you.