I also recently added a Troubleshooting chapter, mostly to deal with common ChromeDriver issues people have been running into. If anyone runs into ChromeDriver issues, give it a look.
germsvel
germsvel
@mstibbard I just added a section in the Authentication chapter that addresses the issue you found. Thanks so much for pointing it out! 
https://www.tddphoenix.com/authentication/#testing-invalid-authentication-credentials
2
bottlenecked
Hey, thank you for taking the time to write this book!
I’ve got some experience programming but never tried true TDD, so after listening to the podcast episode I was curious about how strict one could get while doing TDD and decided to give your book a go.
I’m now at the point where ExMachina is introduced for the first time in the book, and would like to leave some (unsolicited obviously!) feedback about a little thing that bothers me in the few pages I’ve read so far: I guess I would appreciate at the start of each chapter/section a little summary of what the goal of the chapter is and how we’re going to go about it. I feel like I’m blindingly following the instructions like “copy this” and “create that file” and “add that dependency” without really understanding why, and I find that I frequently have to stop or skip a few paragraphs ahead to see where it is that these instructions will lead to and it is somewhat distracting to me.
Anyway, please don’t let any negative feedback bog you down- good on you for going all the way of creating a book to share your knowledge. Much appreciated!
2
bottlenecked
OK. I’ve now gone through a bigger chunk of the book (adding authorization now) and I believe I understand the style better: essentially making a plan and executing it goes somewhat against the TDD style this book looks to impart (not sure if everyone practices TDD the same way so I’m reluctant to generalize), as the whole point is to “describe what you need to do” in a feature test, and let failing tests guide the implementation. I imagine having laid out a “master plan” of what will be attempted for each chapter would “spoil” this TDD approach and readers would be perhaps tempted to jump ahead and work on the code first instead of the tests first.
I guess this is me trying to say that I was wrong in my earlier assessment- perhaps what’s missing instead is a re-affirmation of trusting in the process at the start of each chapter to quell this feeling of unease some readers (like me) might have. Again, good job @germsvel!
PS: based on the talk in the podcast (and personal experience now 
) the editor setup is important for TDD to make the whole cycle faster, so by following these posts here (thank you @atomkirk & @robottokauf3- I hope I’ve tagged the right people) Elixir TDD in VSCode and Visual Studio Code Setup For Elixir Development I wanted to share my VSCode setup for running tests:
ctrl + t; f: run all tests in current file (useful to start the cycle)ctrl + t; ctrl + f: run all failing tests (going with the flow this ends up running the latest test being worked on)ctrl + t, t: run all tests (running this during the refactor step to make sure nothing’s missed)
3
germsvel
Thanks for the suggestions @bottlenecked.
at the start of each chapter/section a little summary of what the goal of the chapter is and how we’re going to go about it. I feel like I’m blindingly following the instructions
I think this is great feedback. I don’t want the book to feel that way.
essentially making a plan and executing it goes somewhat against the TDD style this book looks to impart
I don’t think having a master plan goes against BDD/TDD. In fact, I think not considering design or approach is a misunderstanding of TDD for a lot of people. We can’t completely check out brains at the door and follow errors. We have to consider the design.
When I go through each chapter, I have a master plan in my head, but I imagine I’m just not communicating it enough. So, I think your original feedback is very helpful.
One question I had, how detailed a plan are you thinking of? I have something in my head when we talk about a master plan, but I wonder if its the same thing you’re thinking.
If you have a sense of what kind of master plan would be helpful, let me know. And thanks again for the feedback.
2
bottlenecked
Hey, thanks for not taking this the wrong way 
I only mentioned planning may go against the TDD principles because sometimes to learn something new one has to unlearn some habits, and although having an attack plan is required in the ‘real world’, for the purposes of this book and in order to get the reader to trust in the process and not running off to implement things ‘the old way’ perhaps this style of writing makes more sense. I don’t know really. Happy we discuss this actually!
OK, as to the master plan I was thinking of having before each chapter: a few words on what we’re going to achieve and how. E.g. ‘to create chatrooms we’re going to need a page listing all chatrooms and another page with a form for creating a new chatroom. Also the chatroom page itself, where users will later be able to actually chat. After all is said and done, we’re going to end up with N controllers/views/templates and M schemas. We’re also going to introduce such-and-such library that will help us with this-and-that’.
Anyway, I hope you keep on enjoying the process of writing a book and not getting discouraged by randoms on the internets; I’ve already learned a lot and made me reconsider a few things about tests I’ve written in the past.
2
WestKeys
Why did we pick Doorman over phx.gen.auth?
Thanks 1M for making this tutorial, going to attack it this weekend
1
germsvel
I think a little bit of this in each chapter could be really helpful. Thanks for suggesting it.
Anyway, I hope you keep on enjoying the process of writing a book and not getting discouraged by randoms on the internets; I’ve already learned a lot and made me reconsider a few things about tests I’ve written in the past.
Glad to hear that! 
And not to worry. I’m not discouraged by randoms on the internet 
. I really do appreciate the feedback. I want the book to be valuable to people wanting to learn TDD & BDD.
Thanks again. If you have other thoughts, comments, or suggestions, let me know.
2
germsvel
Why did we pick
Doormanoverphx.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)
5
bottlenecked
Hi there, I’ve now gone through the book (a good read too!) and have started building a new CRUD-type website using the learnings from the book- i.e. TDD
The thing I keep bumping in to is this: how do the Phoenix generators fit in with the approach advocated for in the book? Just by doing a mix phx.gen.html foo bar one gets a ton of functionality out of the door that is honestly too good to pass by for a simple CRUD app. It doesn’t make much sense starting with the bare bones FeatureCase and going through all the red-green-refactor cycles, because the generator will let you skip on a ton of those, prepare tests for you etc.- stuff that I really don’t want to miss out on because of the speed of development they afford me.
So I guess what I’m trying to say is maybe this: perhaps another section (another chapter? edit an existing chapter?) in the book that would adapt the TDD/BDD process to what the Phoenix generators provide out of the box would really help guide the readers on what e.g. your views on the generators are, or if/how they fit in with your test-first approach etc. I think that not acknowledging the convenience of the generators might lead to missing a chance of getting wider adoption of this technique because it might not be obvious how to merge the two.
Once again, thank you for the book and do not feel obliged to cater to every single wild idea on the internets!
0