3 ms·

I have seen this sentiment in people (including my younger self) that have never felt the reassuring feeling of tests really having your back: the ability to ma

by 9dev 3y ago

I have seen this sentiment in people (including my younger self) that have never felt the reassuring feeling of tests really having your back: the ability to make a change to a code base, and being certain the public API of the code continues to work as expected is an incredible benefit to maintainability. Having a comprehensive test suite doesn’t mean the code is infallible and you won’t have to fix bugs, but with every bug a new test increases the future resilience of the code. And finally, tests enable new contributors to work confidently from day one. I agree that tests are a liability, but the amount of testing we do in software is still laughable in comparison to any other engineering discipline.

milianw 3y ago
well said! doing large scale refactorings or invasive performance optimizations without a sound testing infrastructure is a huge pain. the more often you run into this, the more you'll appreciate tests going forward. but as always, one must not forget the pareto principle and related mantras - don't aim for 100% test coverage, roughly 80% coverage in 20% of the time will often give the biggest ROI.
lll-o-lll 3y ago
Yeah, but it’s the type of tests that are often the problem. You need tests that cover the functional (and as much as possible, non-functional), requirements of each “component”. In practice, we tend to have a pile of tests that helped the developer write the code, but now are simply redundant. Then you have all the tests that assert on internal details (strings in error messages anyone?). My favorite guide to testing well is in “Large-Scale C++ Software Design” by John Lakos. The problem at its heart is one of engineering practices. Structuring code bases physically into definable components/modules, interacting only via defined api’s/interfaces and providing test suits that both document and verify the contracts. Done right, refactoring/rewriting involves no, or extremely minimal, changes to the tests. It can be done right, but it requires significant discipline.
scaryclam 3y ago
Exactly. A decent test suite will do two things: 1) Give you confidence that if you refactor something, when you do something silly it'll break the tests and show you where you went wrong quickly 2) Allow you as a developer to write new things in isolation, so you can run the code without needing to jump through any hoops to see that it's correct I tend to write tests when the thing I'm developing isn't simple/cheap to access. Writing tests should help you do things faster, as well as stopping future you from doing daft things. Writing tests dogmatically however, is a waste, and if tests are hard or onerous to write, it shows that the application is probably poorly designed and architected.
valenterry 3y ago
Depends very much on how stable the API is. Because every change can now be much harder, to a point where it is avoided. So it's a balance.
btasker 3y ago
> And finally, tests enable new contributors to work confidently from day one. Exactly this. If I run into an issue when using OSS, I tend to try and look at contributing a fix back. The projects where this is most successful are those with a good range of tests - I don't have the time to sit and learn the workings of a project inside out for the sake of a single fix, a good test suite helps reassure me (and them) that I've not inadvertently broken something. That same benefit exists for new starters working on closed source codebases - they can hit the ground running much faster, confident that tests will help make sure they don't accidentally blow things up. But, the OP is also right that tests need to be written in the correct way - built based upon the intent, rather than the code that was actually written (where I can, I tend to try and write a test first - even if I might later need to go back and tweak it)

by 9dev 3y ago

milianw 3y ago

well said! doing large scale refactorings or invasive performance optimizations without a sound testing infrastructure is a huge pain. the more often you run into this, the more you'll appreciate tests going forward. but as always, one must not forget the pareto principle and related mantras - don't aim for 100% test coverage, roughly 80% coverage in 20% of the time will often give the biggest ROI.

lll-o-lll 3y ago

Yeah, but it’s the type of tests that are often the problem. You need tests that cover the functional (and as much as possible, non-functional), requirements of each “component”. In practice, we tend to have a pile of tests that helped the developer write the code, but now are simply redundant. Then you have all the tests that assert on internal details (strings in error messages anyone?). My favorite guide to testing well is in “Large-Scale C++ Software Design” by John Lakos. The problem at its heart is one of engineering practices. Structuring code bases physically into definable components/modules, interacting only via defined api’s/interfaces and providing test suits that both document and verify the contracts. Done right, refactoring/rewriting involves no, or extremely minimal, changes to the tests. It can be done right, but it requires significant discipline.

scaryclam 3y ago

Exactly. A decent test suite will do two things: 1) Give you confidence that if you refactor something, when you do something silly it'll break the tests and show you where you went wrong quickly 2) Allow you as a developer to write new things in isolation, so you can run the code without needing to jump through any hoops to see that it's correct I tend to write tests when the thing I'm developing isn't simple/cheap to access. Writing tests should help you do things faster, as well as stopping future you from doing daft things. Writing tests dogmatically however, is a waste, and if tests are hard or onerous to write, it shows that the application is probably poorly designed and architected.

valenterry 3y ago

Depends very much on how stable the API is. Because every change can now be much harder, to a point where it is avoided. So it's a balance.

btasker 3y ago

> And finally, tests enable new contributors to work confidently from day one. Exactly this. If I run into an issue when using OSS, I tend to try and look at contributing a fix back. The projects where this is most successful are those with a good range of tests - I don't have the time to sit and learn the workings of a project inside out for the sake of a single fix, a good test suite helps reassure me (and them) that I've not inadvertently broken something. That same benefit exists for new starters working on closed source codebases - they can hit the ground running much faster, confident that tests will help make sure they don't accidentally blow things up. But, the OP is also right that tests need to be written in the correct way - built based upon the intent, rather than the code that was actually written (where I can, I tend to try and write a test first - even if I might later need to go back and tweak it)