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.
Oo nice! Looking forward to seeing it 
I would love to see it cover the topic from the ground up. So assuming that people have not tested previously - even if you speed through such parts. I think having beginner material not only widens the audience but would make the book feel more complete and accessible too.
I would not shy away from opinions either. As you’ve probably noticed there has been a lot of discussion about testing on the forum, and so referencing the position of others and allowing the user to follow their own path could be a nice take on the topic? Either way interested in hearing your plans for the book! 
Personally I read a book on testing when I was learning Ruby but never really bothered with testing. I’d like to change that with my Elixir apps 
The thing I miss the most would be spies and stubs ( looking at sinon.js ). Most people end up creating mocks when in reality they don’t need them. It just happens they don’t know about spies for example.
I am a believer that when it comes to designing tests, code and architecture, the simplest solution is usually the best. That’s why in over 2 years of programming I have never used a mock.
In Elixir I find that the solution for everything is just a mock ( mocks should be used carefully ).
Another thing I miss are the basic concepts that made ( at least for me) TDD viable, such Dependency injection and Inversion of control. I know I how to them JavaScript style, but as I said before, I want to write Elixir instead of writing JavaScript code using Elixir.
A section detailing any of these would clearly up my interest as I have found little information regarding the application of such techniques in the Elixir community.
I have also recently learned about Elixir’s love for property testing which I am new at ( coming from other backgrounds it is the first time I hear about it). A comparison between TDD and PT or how they can be combined together would be interesting to me.
Do note these are my personal opinions based on my personal struggles with Elixir. I have been a seasoned developer in other languages, but coming here I feel there is a lot of adaption needed.
I may not be a good representative of your target audience, you may not be writing a book for people who moved to Elixir after years of JavaScript or something else.
Everyone is entitled to their opinion and as I stated, TDD / BDD is not the holy grail. It may not save you from your demons, but I assure you it has saved me from many ugly demons over the years. It works for me and for the work I do, so I’ll keep defending 
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).
I wonder whether building contractors have to defend using a double mitre saw over a skilsaw for certain jobs; Similarly, when I worked in the pharmaceutical industry, I never had lab managers argue the virtues of liquid over gas chromatography because they have their clear uses. I know that these sorts of discussions happen everywhere but us programmers seem particularly attached to just a subset of all possible tools.
TDD, BDD, test-after-the-fact, the-code-is-so-simple-I’m-not-even-gonna-test-it - all tools in your toolbox. Use them carefully; the trick is knowing what to apply when ;-). Usually, during my rare full days of coding, I go through them all.
With TDD you can write and rewrite a function until it passes your test while you are not understanding what you are doing. It is important to understand what you need. When you can formulate (above code level) what you need you can write maximally comprehensible code (and design the best tests).
Databases, APIs, Cache, basically entire services. The idea here (a according to the elixir community ) is to create a contract and then create an implementation for that contract as well as a mock ( or a fake implementation ).
Then depending on the environment you either use the real object or a mock that implements the contract. ( do note that by definition, your real object also implements the contract ).
I am still not convinced with mocks, I pretty much prefer to simply pass the functions I am going to need down the line ( Functional DI, shout out to @peerreynders for the video link ).
The issue with this is that your higher level functions will have a ton of dependencies, no matter what … So I guess this is where the argument for mocks could take place …
Why do you need test/mock database (or 3rd party api, cache and etc.)? Given that you’re not writing database, 3rd party api or cache library.
You either receive correct response from them or you don’t. You need to mock data, not services.
But that’s just my (incorrect?) opinion and one of the main reasons I’ve fell in love with fp/elixir.
It’s just functions (grouped in modules) that work on data - simple and elegant.
You need to mock them so you can do what we call “contract tests”. In short you need to:
If you don’t understand what i mean by any of this, I recommend you watch “Integration tests are a scam”.