J B Rainsberger Integrated Tests Are A Scam HD

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: link to this video

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: link to 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.

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 pyramid1 and "integrated tests are a scam"2, which is a tad click-bait, but actually quite good. 1 link 2 link to this video

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 link to this video 2 link

…ning io code is just calling other functions and doesn't need to be tested. Several other ideas that relate to this are hexagonal architecture, Domain Driver Design, clean architecture and functional core with an imperative shell. Some resources to further explore these ideas: Clean Architecture in Python - link Why integrated tests are a scam - link to this video Boundaries - link…

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. link to this video