In normal production code you’d expect to ship it would be correct to put all implementation code on src/ and keep tests in test/.

However, since this is a book, I put them the way they are so that I could have one test file and one solutions file, and keep them separate from the project code for chapters when I was working on them. It reduces some amount of scattering and made it easier for me to just focus on the exercises, while also simplifying the annotations internal to source files when selecting subsets that get to be included in the book.

A reader downloading the code archive would also be able to look at the project without getting its code interspersed with exercises, which they legitimately my want to skip over, which is something I wanted to avoid as a potential confusion here.

One of the things not seen by the reader (by design), for example, is that I wanted all code to be testable for the book, including failing cases. So there are chapters there are 3 or 4 copies of a module existing. In chapter 3 it’s possible I had src/thinking.erl (final version), src/thinking.erl.a (first iteration shown), src/thinking.erl.b (second iteration), and so on.

This is something I could do so that if PropEr got upgrades while writing the book, I could go back in and re-generate the snippets for result sets in a way that wouldn’t require me to re-write everything every single time, while still leaving an artifact on disk that the PragProg editing system can bring into the page.

What I’m saying here is that the choice of where to put the code in this case is one of code organization related to the book and its authoring process, and specifically here, keeping exercises and solutions separate from the chapter’s project both for my sake, but also for the sake of readers who might want to look ahead in the code bundle that ships with the book without caring for the exercises.

The code has a distinct purpose from shipping software, and its organization may reflect that.

A note on the last comment there: there is far less thought going into which order to put functions in the assertions than you are implying here. My other response mentions a possible approach I could suggest in general, but at the time of writing it the book, I didn’t ask myself that question at all, and I don’t think it really matters ultimately due to being in comparison. I think I can suggest swapping the order from what I typically write, but I would never call it out in a code review, if that helps qualify the strength of how I feel about this.