This is really amazing work! Well done for getting over the “fear” of sharing with the world. Karma+1 for you.

Why did we pick Doorman over phx.gen.auth?

That’s an excellent question. I picked Doorman because it was something simple at the time when I started writing the book (a couple of years ago). But changing that chapter to use phx.gen.auth (or something like that) is in my list of to-dos for v1.

If you’re interested in what else is on the roadmap for v1, I wrote a short list in TDD Phoenix Update (Nov 2020)

I ended up switching to Linux just to follow this tutorial as I never figured out how to fix those Windows permissions, and I can confirm it was well worth it. This was exactly what I needed - fantastic work.

I’d advise new Elixir/Phoenix coders follow this book even if they never intend to do TDD… it’s such a great way of learning as it helps you grasp the logic (and in particular what common errors mean) much quicker than just trial and error. Although I have a feeling most people will be keen on TDD by the time they are done

This book is exactly what I have needed. I remember when I started developing in Rails there was a TDD book that really helped me fully understand the development cycle. For the longest time it was what I gave credit to my first dev job.

I moved to Elixir/Phoenix and the one thing my applications felt missing compared to my Rails ones was my test suite. I was confident in most of my Rails tests because I 100% TDD, but the tests I was previously creating for elixir were not near as good. This book definitely gave me the perspective I needed for the current Phoenix project I am working on.

I did have problems running the async tests with Wallaby, so I cheated and just limited to number of async tests I can run to 1 with mix test test/chatter_web/features --max-case=1 to make the tests pass. I was using a Mac with chrome driver.

Hi @tjdam, thanks for reading the book.

I may be head of myself here, but it seems like the type of workflow you use in the book with Wallaby and all would be the best fit for the type of apps I’m building?

I think I understand your question, but please correct me if I misunderstood it.

When I build APIs, I follow the same outside-in process that I follow in the book. The difference is that the outermost test is usually a controller test (or something equivalent). So you would not need Wallaby.

Wallaby’s purpose is to emulate browser interactions in our tests. Since you’re building APIs, that’s not needed. But the rest of the outside-in process should be the same.

Whatever the application’s domain, I usually try to find the test that best describes a feature for my customers. In APIs that tends to be an endpoint. So that’s where I define the outermost test, and then drive the implementation from there.