gvwilson
A simpler example in the Testing chapter
I mostly work in Python, and would say I have an intermediate level of familiarity with pytest and testing in general. However, I work on data processing & analysis, not web applications.
Reading the chapter on testing, I felt like it quickly got into some pretty complex examples of fixtures and expected/actual results with the MVC pattern, mocking, and recorded GUI interactions, which I found difficult to follow even with some experience writing software tests. I think it would have helped me understand what was going on if the "fixture" and expected/actual result" language that's introduced at the beginning were used throughout the examples. Having at least one simpler explicit example early on might also help make the analogous parts of the more complex testing scenarios easier to identify later on, especially if they're all identified using the same labels.
In the "What's Hard to Test" section, it wasn't immediately obvious to me why the visualizations would be hard to test. Thinking about it for a second with some experience writing tests it becomes clear, but I think another sentence highlighting the fact that there are many different visual outputs which will be interpreted as having the same correct content by a human, but the simple test can only check whether you get exactly identical outputs. It seems like there's a good transition to be had there into the concept of testing within some tolerance on floating point calculations. Except that defining "close enough" for an image is much more complex than an array of floats. Actually maybe it would be better start with the floating point example, which is very explicit and clear, and then talk about images as an analogous case that's much harder to address because the idea of a tolerance in image similarity is so much more complicated?
I hope these comments feel constructive. Thank you so much for creating this book (and your others)! It's a great resource that I think will be valuable well beyond the university student context it's directly addressing, and I'll definitely be recommending it to folks that I work with in the energy & climate policy space that are trying to move some of their analytical work toward using programmatic tools, instead of spreadsheets.
I'd agree that for readers without knowledge of web architecture this example is unapproachable. To address the issue of designing for testability, would it be helpful first to introduce the concept of architectural layers? One might, for example, discuss how a program can be thought of as three layers:
- Presentation layer: talks to the user;
- Application logic: coordinates and sequences actions
- Storage logic: Maintains a persistent store of application data
The layers are defined (or can be) in terms of how far from the user they are. A simpler example could then be formulated using terminal i/o and flat file storage.
