3 ms·
Most of this is a series of false choices. In fact - tests can help show code quality improvements do not break anything - you can have integration tests and
by humanrebar 7y ago
Most of this is a series of false choices. In fact
- tests can help show code quality improvements do not break anything
- you can have integration tests and unit tests at the same time; in fact, it is more of a spectrum than two rigid categories
- it's often possible to have simple code and test it
Generally speaking the more specific the question, the less controversial the choices are. It's typically not all that interesting to argue about how to test a particular algorithm, data structure, or service.
The hard part in all of this, from an engineering perspective, is just talking to folks, promoting good teamwork, actually showing the value of less obvious things (a passing test suite), and knowing what to do when technology choices become toxic to the product or team.
- barrkel 7y agoMost interesting refactorings change the boundaries and count of abstractions, which usually does break unit tests. Unit tests are great at the leaves of the call graph, and things which are almost leaves because their dependencies aren't at any real risk of change. The further into the stack you go, the more brittle they get.
- humanrebar 7y agoThe point is that I use all kinds of tests all the time. It works fine. You aren't required to join a tribe and debate about abstract test styles. Look at the current problem and come up with good answers to the questions: - How do we know it works? - How will we know it still works in a year? ...you don't always need the best answers, even. Most projects should start with honest answers and work from there.