|
|
|
|
|
|
by avl999
1382 days ago
|
|
|
Software isn't written once and left to run in production for it's lifetime, it is constantly being iterated on and changed. And a lack of tests will inevitably result in a slowdown of the rate you introduce new features as now you need to spend longer convincing yourself that the change you made didn't inadvertently break something else (plus rolling back and outages that will result from such an event). Most tests written by people working on the product will of some baseline level of quality and even if they weren't, even if they were "bad tests". It is much easier to fix bad test than it is to deal with an application on a day to day basis which has no tests. |
|
|
This is exactly the mindset I'm talking about. Lack of which tests? Manual? Unit? Functional? Integration? End-to-end? Doesn't matter, right? All tests have zero cost, the more the merrier.
And when exactly does the slowdown happen, on day one? Or maybe some time in the future? Do we have a way to tell when exactly should we write tests, how many, and which ones? Most of the time the mindset is "we don't have tests, therefore we need tests". Cargo cult at it's finest.
> Most tests written by people working on the product will of some baseline level of quality
Not in my experience. Tests are often introduced before you have a good understanding of the domain (hello TDD). Epitome of that is hiring junior engineers, realizing you don't want to assign any real work to them, and forcing them to write tests.
> It is much easier to fix bad test
Typically bad tests should not be fixed, they should be thrown away. But pretty much every company sucks at deleting bad tests, because there's the illusion of value they provide.