Andrea Leopardi and I are currently writing a book on testing elixir for PragProg. While it does not emphasize TDD, I’m a strict test-driver. I’m not sure what resources need to be dedicated specifically to TDD if you are already familiar with the concepts from another language.

Let me know how I can help and I’m happy to. I do not know of any specific guides or posts.

You also have ExUnit Official Documentation to start with.

I do not know a book dedicated to TDD in Elixir, but testing is not an issue for me, it’s more like a pleasure after using RSpec/Rails. It’s really damn fast. You don’t even have time to get a coffee while running the full tests

But You need to test different things, like macro testing, OTP testing (You can assert that a process has/has not being called).

Others resources You might find useful.

• There is a dedicated testing chapter in Mastering Elixir (Self-published / Packt)
  • It covers all sort of scenario… mocks/or not, channels testing, macro testing etc.
• If You want to test with Phoenix, You have Programming Phoenix (Pragprog) which includes tests.
• The same goes for GraphQL and it’s related book Craft GraphQL APIs in Elixir with Absinthe (Pragprog).

You might ping @peerreynders for a wise advice on the subject.

I’m not exactly sure what you are expecting.

GOTO 2015 • Agile is Dead • Pragmatic Dave Thomas:

(I seem to recall that he stated of typically having about 60% test coverage.)

Anyway - TDD is a practice and if you have a competent testing framework like ExUnit you should be good to go - what other language specific support do you expect? And thanks to the Erlang community there is PropEr to replace some tedious static test cases.

Keep in mind that any practice should not be taken to the extreme of religion or dogma - that is counter-productive.

Practice TDD when it makes sense but keep in mind that it is just as important to delete those tests once they taught you all they can so that you don’t have to pay the cost of maintaining them (and don’t make the mistake of skipping Refactor in: Red, Green, Refactor - Why Refactor? - Economics).

DevTernity 2017: Ian Cooper - TDD, Where Did It All Go Wrong

Nope.

You can blame Steve Freeman for that answer, he planted it in my mind. We had a coffee (or, probably more likely, a beer) and were chatting about JMock (created by him and others to basically help out with “London School” style TDD-ing) versus all the other mocking libraries and frameworks that were out there.

A lot of users of the other frameworks mocked (couldn’t resist) JMock for being so “primitive”, sometimes going ad hominem, blaming its authors for not understand enough Java to do a “proper” implementation.

Knowing Steve, I knew that that was false. So I brought it up and he said that JMock was intentionally kept simple, and they tried to tune its functionality to do one thing:

Drive good designs.

The goal is that if you cannot JMock it, that’s not a library limitation, it’s a design smell in your code and you need to go and fix it. The other libraries don’t help you there, as they will allow you to mock pretty much anything under the sun (he advised that you should use JMock for your own code and grab one of the other ones in case you need to mock library stuff, because most libraries in Java are just horribly written).

That made something click in my mind, and since then - I think it was a bit under ten years ago - I’ve been looking at how people test in various languages; and they’re on to something. The more powerful the tools, the worse the test suites and the code design (Rails tops it; never, ever, listen to people called DHH for any programming advice). These libraries and frameworks can just walz through anything; they’re akin to just using heavy powertools while trying to learn fine woodworking.

I think that ExUnit is sufficient; the only thing that’s usually hard to test is a GenServer, or Agent, etc; either I call the server-side methods directly, or I pull the business logic out and then the GenServer itself just forwards messages and then becomes “obviously correct” - a term I use for code that doesn’t need testing. Dependencies can be passed in, it usually is not a lot of work. Most of the tools, like ex_mock, come with serious drawbacks and let you get away with murder. Don’t give in to their temptation

At the risk of stating the obvious:

• When dealing with function values nothing much changes. Pass in your fake function instead of the real function and have the fake do what it needs to do.

• However Elixir doesn’t have Objects. In JavaScript Objects conflate (mutable) state and behaviour. In Elixir state is stored in immutable data structures while behaviour resides in modules.

So it’s:

someValue = state.method(...params); // spread params array over arguments

versus

new_state = Module.function(old_state, params) # params is a parameter key list

So in Elixir the “fake object” situation may require a fake data structure (though at times you can simply use the real one) and will require a fake module, which means that your mockable boundary cannot hard code the module so that we can write:

new_state = apply(Module, :function, [old_state, params])

with the rough JavaScript equivalent:

someValue = (state.method).apply(state, params);

Now in Elixir that Module value has to come from somewhere and typically that is resolved at compile time (something that JavaScript doesn’t have) by grabbing the Module from the compilation environment - i.e. compilation in preparation for running tests versus running the application.

This is essentially what Mocking and Explicit Contracts and Mox are based on.

Consequently choosing mockable boundaries in Elixir is a much more deliberate process (hence “Explicit Contracts”) than it typically is in JavaScript with the ad hoc creation of injectable spies (where state has customized behaviour already bound to it).

(Another example)