Good Elixir TDD resources?

There are a lot of books with a dedicated chapter on testing, but a book dedicated only on tdd, not really…

I think there is a tdd based development in Phoenix Inside Out, but I did not read it, and maybe someone can confirm.

There is a book dedicated on testing only, it is

But it’s all about property based testing which seems to be a new way of testing.

Anyway You will see that testing in a functional world is a breeze (mostly no side effect), and tests are incredibly fast (run concurrently).

Are there any other resources you know of? I have the feeling there is a distinct lack of resources about testing in this community.

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 can confirm the author @shankardevy follows TDD in his Mastering Phoenix Framework book where you develop an e-commerce site called Mango. Each chapter begins with an iteration planning section including user stories, then writing acceptance (browser) tests using Hound, then ExUnit tests, finally writing the implementation until the tests pass green. You can see the code of the finished product/site here: GitHub - shankardevy/mango: Ecommerce site that you will build while learning Mastering Phoenix Framework · GitHub

I’ve collected pretty much all Elixir/Phoenix books by this point and his is the only one I’ve found that is strict about TDD/writing tests first and I have to highly recommend it.

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

So, in JavaScript where I originally come from, I used to do TDD using a variety of tools: Mocha, Sinon, Chai, supertest, etc.

These tools used to help me with spies, stubs and mocks, servers and you name it. Some people will tell you that they just use the Node.js assert, and only use that function to test everything and anything, but I would respectfully disagree with them.

Regardless of that, I learn how to do dependency injection, inversion of control and a myriad of other techniques using such tools to test my applications. As a consequence, none of the apps I tested well ever had issues. In fact, they saved my skin.

Oh, so you are a fanatic!

Well, well, let’s calm down. I have actually seen GOTO 2015 • Agile is Dead • Pragmatic Dave Thomas before. I don’t agree with many of his opinions, but he also makes some pretty good points I agree with.

I don’t see myself as a fanatic. I am of the belief that having 100% coverage is ncie but I will definitely not fret if I don’t reach it. I rather have tests that make sense rather than tests that just bump up a random percentage.

However, given the projects I am in and how much I have benefit from TDD in the past, I am of the strong belief that applying it in my projects makes sense and fits.

I don’t say TDD is the holy grail of salvation. It won’t work for everyone. But for the things I work on, it’s actually pretty great.

Fl4m3 Snow, you know nothing!

I can pierce into some of your brains and see what you are thinking:

You only think you know TDD, but you don’t. In reality you have depended on a set of tools to do testing, while you needed only a basic assert, so without those tools you feel lost because you know nothing!

Well, I wouldn’t say I know nothing. The way I see it,I know some stuff, but I wouldn’t say I am a master either.

YEah, yeah, what do you want?

Well, I was looking for a resource that would present me with a similar set of tools to the one I used in the past. A library to fake spies and stubs and mocks, an assertion library, and explaining how to do tests with such tools and the conventions the Elixir community uses. I want to write Elixir tests after all, not JavaScript tests written in Elixir.

I hope this sheds some light on the kind of person I am and on what I am looking for!

@kokolegorille For now, I just want to learn how to do TDD in Elixir. No Phoenix or frameworks. That’s for another time

I do have to say that the ExUnit docs are rather … well for me, it is hard just by reading the docs to see how I can stitch up each function and make a coherent test suite. As for testing in FP… side effects are always present.

It is my challenge to isolate them and test them properly that led me to the magic world of Monads, which I am still considering ( but I take it most people here don’t really like Monads? ).

@tme_317
@kokolegorille
Also the book Mastering Elixir looks nice, but the testing chapter is mainly a warmup for how to test using Phoenix. Since we don’t use it in the project, I don’t believe it makes much sense.
Maybe I missed something from the online preview?

This one comes to mind: Why I use Tape Instead of Mocha & So Should You

Anyway Elixir has a set of "assert"s under ExUnit.Assertions - including ones to test the presence or absence of mailbox messages.

And there are utilities that people “just whip up” when and if the need arises, example: TaskAfter.

Sometimes it’s just more effective to create exactly what you need yourself, rather than to having to learn some other tool or more general library when you only intend to use 5% of its capability.

I learn how to do dependency injection, inversion of control and a myriad of other techniques using such tools to test my applications.

While those design concepts are helpful when it comes to testing and designing for testability, they are not testing centric but rather general software design concepts. For example: Inversion of Control Containers and the Dependency Injection pattern.

To get a notion of the general attitude towards mocking see Mocking and Explicit Contracts - and there is Mox for mocking behaviours (and there have been discussions around Mox like this one).

I do have to say that the ExUnit docs are rather … well for me, it is hard just by reading the docs to see how I can stitch up each function and make a coherent test suite. As for testing in FP… side effects are always present.

You could always try “learn by example” - e.g. pick a project (e.g. Plug or start small with ExUnits own tests) and investigate how testing is approached there. By the time you’re done, you’ll likely know the project as well.

Already searched the forum with tdd as keyword? You will find BDD / TDD criticized . About the ruby community and testing: see links to DHH’s criticism in that thread also (I at least think I pasted them there).

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

Many developers focus on unit testing (for clearity: “a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of any software. It usually has one or a few inputs and usually a single output.”). DHH warns against harming architecture while making software unit-testable. Coplien does that too: “If you find your testers splitting up functions to support the testing process, you’re destroying your systemarchitecture and code comprehension along with it. Test at a coarser level of granularity.”. And: “You’ll probably get better return on your investment by automating
integration tests, bug regression tests, and system tests than by automating unit tests.” See the link in my previous message for the references.