Hacker News Reader

I primarily try to aim tests at the public API contract. This is a long promise so the code churn the author mentioned should not be affected.

Testing internal details is technical debt.

If your change has not effect on the public API contract... why are you doing it? Think harder...

View on HN

I've seen a lot of terrible tests over my career and some of the most egregious examples seem to have one thing in common: mocking frameworks. By definition the test code becomes very highly coupled to the implementation details of the code under test. Rather than being a "safety net" to enable fearless refactoring, they become a huge impediment. I now lean towards only public API testing too, but still monitor test coverage. Sometimes this means I write only integration tests, but I'm fine with that. Test coverage is usually still very high. Tests are more meaningful, and usually simpler. If code can't be hit through the public API, then it's candidate for deletion. So much of our profession seems to be built on unjustifiable dogma, and I think it's great we're starting to see some thoughtful challenges to this. (The recent pushback against thoughtlessly reaching for microservices as a default option is another good example).

Couldn’t agree more! Test the system from the outside. Don’t test the internals. It’s a waste of time.

Reply on news.ycombinator.com