Hey there!

Really nice video!
At first I was quite confused. I usually do TDD from the inside-out, I think about my application’s domain first and I test it like most people from the London school of TDD would - first I define a public API for my domain, and then as I implement it I use a recursive strategy similar to Discovery testing:

• Discovery Testing · testdouble/contributing-tests Wiki · GitHub

Once I have my domain fleshed out, I then proceed to adding layers on top of it, such as an HTTP layer with Plug, or a Terminal layer or something else. This architure really likes having different repos or umbrella projects. If this sounds confusing, reading my review on Designing Elixir Systems with OTP will help you understand it:

• Designing Elixir Systems with OTP (Pragprog) - #53 by Fl4m3Ph03n1x

So when the video first started, I was confused. Why is he starting with HTTP first? Our application is not an HTTP app, HTTP is a detail, our app is a Greetings app. And then I got more confused when I realized both the Plug and the E2E tests were the same thing.

But as the video goes on, you actually refactor the code several times and make the division clear, eliminating and remaking tests. I really liked it. It really started making sense towards the end.

You end with Mox and Mocks. Now … This is where things get interesting for me. I have tried using Mock test doubles (not the library) for the longest time but I can’t! (PFFFF, and you call yourself a London TDDer? Shame on you!).

Hold on with the pitchforks!
I just inject my test double directly. This means, I just inject the functions I need. In other words, I inject the dependencies the SUT needs into the SUT. So, when I want to test, I just pass around 2 - 3 functions (that I stub) and I test my code that way.

The issue then is that I have a lot of configuration code lying around. I thought Mox would help, but it kinda feels like overkill, to be forced to define an interface for every module doesn’t really convince me, given the simplicity of just passing a function.

Mocks looks interesting, it looks to me like they focus more on making stubs explicit, but then again, I am still not convinced when comparing this with the simple “just pass the function you need” solution.

So this is where I am at. I must say this Outside-In journey, although different from what I am used to, was really nice and opened my eyes to E2E tests while reinforcing my notion of testing colaborators. The way you speak makes me think you have seen “Integration tests are a scam”:

• Beware the Integrated Tests Scam (was Integrated Tests Are a Scam) - The Code Whisperer

TL;DR

Nice talk, make sure you watch it fully until the end or else you will miss the wrap up where most of the value and hard questioning is.