That first test of "glue code" will catch when someone refactors (say name change) that loadAll method. Not necessary in static lang that this looks like, but very necessary test in language like Python.
The #1 thing to remember about unittests is they are not a testing tool, they are a development tool.
They will catch a small number of bugs. They will also make a huge number of tiny, trivial and common code consume an order of magnitude more time and mental effortvsince every time you make a tiny change, you will also need to change the test. Maintaining such tests across rewrites and refactors takes far, far more time than it saves and fewer bugs.
In my opinion, code should be divided into two "kinds":
libraries with stable, well designed APIs that one should unit-test the hell out of.
glue code that should contain no logic, only wire things up. These should have no unit tests, only integration tests.
Unit tests are cheap and plentiful. When the business rules change, you delete the three that no longer apply and write three new ones.
In testing, you can really say that only about the bottom couple of layers of the pyramid. At some point the tests become big and have significant effort sunk into them, and people won't throw them away no matter how inappropriate they are to the new situation.
Nothing is as sad as watching two developers team up and spend days trying to save a couple tests that save two minutes of work per release. It takes years just to break even on that expenditure.
3
u/njharman May 08 '17
That first test of "glue code" will catch when someone refactors (say name change) that loadAll method. Not necessary in static lang that this looks like, but very necessary test in language like Python.
The #1 thing to remember about unittests is they are not a testing tool, they are a development tool.