Software Design by Example in Python 6: Running Tests

Having written a bunch of tests while building the parser and pattern matcher in the previous chapters, it was long past time to show learners how to build a testing framework like pytest. In particular, Chapter 6: Running Tests was another opportunity to show that a program is just another kind of data, and that introspection can make a lot of things easier to build but harder to understand. Finding functions dynamically ensures that we don’t ever write tests but forget to run them; however, it means that the program’s text doesn’t contain an explicit list of tests that are going to be run. This tradeoff is intrinsic and unavoidable: higher-level abstractions put more power into experienced programmers’ hands but make their code more difficult for novices to understand. Helping novices become comfortable with those abstractions was the main goal of this book and its predecessor.

Terms defined: actual result (of test), assertion, dynamic typing, error (result of test), exception, expected result (of test), failure (result of test), fixture, global, local, pass (result of test), pretty print, raise (an exception), register (in code), scope, unit test.

And now a request: if you have experience implementing support for dark mode in browsers and can submit a PR to change the CSS for this project, I’d be very grateful for your help. I believe the solution is going to involve a media query, redefining some colors, and using the CSS invert function to make the SVG diagrams white-on-black, but I’ve never done this and need to focus on other work right now. If you can spare the time, thank you in advance.