A practical example of TDD Outside-in with Elixir

joebew42

Hello

This is a follow up for the Good Elixir TDD resources? thread.

It was my intention to make a video about TDD Outside-In with Elixir, and it is finally available on YouTube. The purpose of the video is to provide a practical example, and highlight few points of the practice: test first from the outermost part of the application, baby steps and refactor as part of the process.

More resources can be found on the description of that video (recommended books, example code and further study material on this topic).

Hope this could be a valid contribution for the community, and of course I will be available to continue this discussion, and I am also alvailable to schedule a remote Pair Programming session with whoever want to practice on the same Code Kata

1 comment

#tdd

6 2030 1

2020-03-03 15:29:41 UTC

Showing Posts 1 to 1

Show Best Posts
Show All (oldest first)
Show All (newest first)

Fl4m3Ph03n1x

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”: