J B Rainsberger Integrated Tests Are A Scam HD

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

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

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 leverage property testing to further boost our confidence in such tests. Many times the ramaining 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 - ▶ this video Boundaries - link

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

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.

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