Hacker News Reader

There's been a lot of discussions on Mockists vs Classicists. See Martin Fowler's article: http://martinfowler.com/articles/mocksArentStubs.html. In my experience, projects that use mocks extensively usually have the most bugs. If you also have integration tests then mocks are ok. But then it's more code to maintain.

Given a choice I would always do "integration test". Fact is you can test a single class/method, reality is that no class/method exists alone.

View on HN

We recently implemented an extensive test suite that can be run with either mocks for service dependencies or in a live configuration, depending on config settings. Before, we simply had integration tests that relied on very specific data across disparate services and running it in CI was a nightmare (to the point that we would typically only run the full suite in a QA environment shortly before a production deploy).

Whereas our integration testing has been responsible for catching hundreds of obscure bugs over the past year, most of the bugs found by our mocks have been bugs in the mocks themselves and I expect that issue to compound due to the brittle nature of mocks in general. Mocks make every change some multiple more expensive in both initial cost and maintenance.

Reply on news.ycombinator.com