101–110 of 346 posts
But in my experience, code covering unit tests have correlated strongly with faster development and far fewer bugs being uncovered in the field.
My main issue with unit testing is what defines a unit? Throughout my career I find tests that tests the very lowest implementation detail, like private helper methods, and even though a project can achieve 100% coverage it still is no help avoiding bugs or regression. Given a micro service architecture I now advocate treating each service as a black box and focus on writing tests for the boundaries of that box. That…
I agree with you. That's called functional testing, and it is very useful, but it is not unit testing. Unit testing: Test all methods and paths of a class, even private ones. Functional Testing: Test the public api of a class/service only. If something is wrong internally, it will be caught without having to write countless of little tests. ROI of functional testing is high, as it is usually done with real data. In m…
Of course any metric can be rendered useless if one "works the metric" rather than the intent of the metric. But in my experience, code covering unit tests have correlated strongly with faster development and far fewer bugs being uncovered in the field.
If the metric actually measures the figure of merit rather than a proxy with no necessary linkage, this is not true; working the metric then is working the intent of the metric.
The extent to which a metric can be "worked" distinct from its intent is exactly the extent to which it is measuring something disconnected from what it is used to assess.
Earlier quoted context omitted.
Tests are not meant for ensuring it works with all inputs. You cant simply just throw values at it hoping its all okay. To prove it works with all possible inputs, there are other tools at your disposal.
What tools would that be? I'd like to hear about real world test scenarios where all possible inputs are tested.
I much prefer to use code coverage as a weak indicator for finding dead code.
Earlier quoted context omitted.
I agree with you. That's called functional testing, and it is very useful, but it is not unit testing. Unit testing: Test all methods and paths of a class, even private ones. Functional Testing: Test the public api of a class/service only. If something is wrong internally, it will be caught without having to write countless of little tests. ROI of functional testing is high, as it is usually done with real data. In m…
I think that depends on the code base, I agree with your points for more procedural code bases, but for functional or OO code you should be able to test most of your logic without mocks or wiring too much up.
My main issue with unit testing is what defines a unit? Throughout my career I find tests that tests the very lowest implementation detail, like private helper methods, and even though a project can achieve 100% coverage it still is no help avoiding bugs or regression. Given a micro service architecture I now advocate treating each service as a black box and focus on writing tests for the boundaries of that box. That…
I agree with you. That's called functional testing, and it is very useful, but it is not unit testing. Unit testing: Test all methods and paths of a class, even private ones. Functional Testing: Test the public api of a class/service only. If something is wrong internally, it will be caught without having to write countless of little tests. ROI of functional testing is high, as it is usually done with real data. In m…
The danger of 100% percent coverage is that the goal of tests becomes the 100% code coverage and not bug detection anymore.
Earlier quoted context omitted.
I agree with you. That's called functional testing, and it is very useful, but it is not unit testing. Unit testing: Test all methods and paths of a class, even private ones. Functional Testing: Test the public api of a class/service only. If something is wrong internally, it will be caught without having to write countless of little tests. ROI of functional testing is high, as it is usually done with real data. In m…
Apprantly people misunderstand a unit. Apprantly Kent beck meant unit to mean a single piece of behaviour, not classes or methods. https://www.thoughtworks.com/insights/blog/mockists-are-dead...
Which is just as ambiguous. Personally I stick with the single assert principal (which may be more than one literal assert) so that whatever I'm asserting is the behavior that this test is verifying.
Earlier quoted context omitted.
Indeed. It's almost as if testing should be built into the language itself. (I'm always a big fan of including self-test code in projects)
> testing should be built into the language itself I wonder what that would look like...
In haskell you embed domain specific languages when you require side effects:
class MonadState s m where
get :: m s
put :: s -> m ()
You can use different implementations for production and testing without changing any code so mocking is built into everything.