J B Rainsberger Integrated Tests Are A Scam HD
Why Hacker News recommends it
HN recommends it in testing-strategy debates as the classic case for fewer integration tests and more small, well-contracted unit tests.
What it is
J. B. Rainsberger argues that large integrated tests are a scam: they are slow, fail opaquely, and give a false sense of coverage. He advocates focused collaboration and contract tests at boundaries instead.
Recommended by 4 HN commenters across 4 different months, 2017 to 2023.
What Hacker News said
Recommends pooktrain · 2017-03 · on “Zen and the Art of Unit Testing”
Trying to cover your state space with coarse-grained tests in database-backed applications can lead to slow tests suites that are laborious to set up/tear down, which is a barrier to fast build times in CI. This harms productivity both while writing tests and in deployment. J.B Rainsberger says it best: [this video]
Recommends 1_player · 2017-10 · on “Write tests. Not too many. Mostly integration”
I have adopted the same philosophy. A few resources on this, part of the so-called London school TDD: - [LINK] (and the rest of the Wiki) - [LINK] - Most of the screencasts and articles at [LINK] (especially this brilliant talk [LINK] ) - Integration Tests Are A Scam: [this video] All of these basically go the opposite way of the article's philosophy: Not too many integration tests, mostly unit tests. Clearly define a contract between the boundaries of the code, and stub/mock on the contract. You'll be left with mostly pure functions at the leaves, which you'll unit test.
Recommends mpweiher · 2018-07 · on “Goodbye Microservices: From 100s of problem children to 1 superstar”
Sure. I'd venture to say that integration tests should be fewer than unit tests, see hexagonal etc. Hopefully those external interfaces are also more stable, so they don't need to be run as often. I tend to use my integration tests also as characterization tests that verify the simulator/test-double I use for any external systems within my unit tests. See also: the testing pyramid[1] and "integrated tests are a scam"[2], which is a tad click-bait, but actually quite good. [1] [LINK] [2] [this video]
Recommends mihaigalos · 2022-09 · on “Fit: Framework for Integrated Test”
I've tried FitNesse professionally. I think it comes short in many regards. To be clear, I think integrated/integration tests in their own only add value if you have a couple of them (meaning <5). Otherwise, they're red and no one knows why. And they take a whole lot of time to execute. JBRainsberger has an nice talk on them [1]. Pactflow have implemented a Contract/Collaboration framework called Pact [2]. I haven't used it professionally but I love the concept. [1] [this video] [2] [LINK]
Cites aszen · 2020-10 · on “Prefer Fakes over Mocks”
I have been researching into several testing approaches and so far in my experience yes fakes are better than mocks. But what is even better is not having to fake or mock stuff especially for testing business logic. One of the problems we get ourselves into is abstracting service io code into functions and calling them from our business logic code. This forces us to mock all the io calls, instead we should be doing the opposite i.e abstracting business logic into discrete functions of pure data in and out and then calling those functions from our io code. This way we can test the business logic independently of the io code. Testing the business logic now becomes quite simple and one can leve
Cites Ygg2 · 2023-01 · on “Testing Without Mocks: A Pattern Language”
I think the big issue is. Are you writing a lib or an app? In library you don't need to mock. Library is supposed to be agnostic. In app there are many layers. You kinda need to mock them all, otherwise your app can't be tested. And then you have the problem that minor changes turn your tests red. So mocking is most useful in the place it has almost no impact. [this video]