>but in practice seems rather to lend itself to causing terrible code smells all over the place
I'm working on a code base of about half a million lines at work. We have lots of functional/integration tests, but no unit tests, and the code (C++) is not designed for it.
To add unit tests, we would have to rearchitect a lot of the code.
Last year, as a side project, I took some of our code, rearchitected it, and added unit tests as a proof of concept.
Since I knew I would have to convince management (essentially justifying a lot of churn to add these tests), I had a simple rule:
Every change I make to add unit tests should have some value even if we never add unit tests.
This helped me focus on code changes that I could objectively say improved the code quality, and helped me reject changes that were "just for unit testing".
I'm working on a code base of about half a million lines at work. We have lots of functional/integration tests, but no unit tests, and the code (C++) is not designed for it.
To add unit tests, we would have to rearchitect a lot of the code.
Last year, as a side project, I took some of our code, rearchitected it, and added unit tests as a proof of concept.
Since I knew I would have to convince management (essentially justifying a lot of churn to add these tests), I had a simple rule:
Every change I make to add unit tests should have some value even if we never add unit tests.
This helped me focus on code changes that I could objectively say improved the code quality, and helped me reject changes that were "just for unit testing".