It's a perennial but: unit tests are more about how you think and rigourously approach a problem than preventing regression. I'd say if you wrote unit tests and then deleted them, your code would be better for it. Indeed, I often don't commit some of the tests I've written in order to write the code! I'll ship some subset of them. It's a notebook.
They serve as a form of living documentation for the code and help increase velocity in a build under the right conditions.
For example, you do need to know a certain function does what you think it does because the rest of the system isn't even in place yet. You might have to approach this from the outside, via integration, but the speed of doing this is quite slow. Versus a unit test.
This is not to mention refactoring!
The piece seems to be more about the value of mocking and how far to go with isolation. Which is a slightly tangential issue. I agree that in particular styles of object orientated programming this becomes absurd.
This article, which is linked provides a more convincing case, on the grounds that unit testing foregrounds the system as software as opposed to the software as a useful and functional thing in the world, meeting user needs.
However, it omits the being about to _react_ to user needs is actually a central party of agility. Unit testing allows maximum reactivity to changing requirements without regressions in the code and makes this code navigable. Changing customer needs means your carefully built functional tests are going to be just as useless and rotted. This has been the case with large test suites of functional tests - say in something like Cucumber - I've seen. Better test at a lower level, which moves slightly less rapidly.
They serve as a form of living documentation for the code and help increase velocity in a build under the right conditions.
For example, you do need to know a certain function does what you think it does because the rest of the system isn't even in place yet. You might have to approach this from the outside, via integration, but the speed of doing this is quite slow. Versus a unit test.
This is not to mention refactoring!
The piece seems to be more about the value of mocking and how far to go with isolation. Which is a slightly tangential issue. I agree that in particular styles of object orientated programming this becomes absurd.
This article, which is linked provides a more convincing case, on the grounds that unit testing foregrounds the system as software as opposed to the software as a useful and functional thing in the world, meeting user needs.
However, it omits the being about to _react_ to user needs is actually a central party of agility. Unit testing allows maximum reactivity to changing requirements without regressions in the code and makes this code navigable. Changing customer needs means your carefully built functional tests are going to be just as useless and rotted. This has been the case with large test suites of functional tests - say in something like Cucumber - I've seen. Better test at a lower level, which moves slightly less rapidly.
https://www.sacrideo.us/the-fallacy-of-unit-testing/