4 ms·
I'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 stabl
by bunderbunder 8y ago
I'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.