Test-driven development is, loosely defined, a practice in which tests are written before anything else, without regard to correctness. For example, if I want to write a program to generate “Hello, world,” I would write a test that validated that “Hello, world” was generated – before I had anything that might create the output. When my tests pass, I know I’ve “finished,” because my tests define a specification. By having tests in place, though, not only do I have a record of the specification, but I also have a way that I can add to the specification in such a way that I know I’m not breaking code – I would simply add more tests that corresponded with the changing specification, and I will know if my changes break other code. Here’s the thing: I wrote the Java implementation using test-driven development practices (TDD), and the automaton is kinda neat; TDD also provided me the opportunity to fix the names of structures (renaming `Dataset` to `Generation`, for example) because the tests made it obvious that the names were inaccurate. However, seeing the differences in the development process between my Python implementation and the Java implementation, I might look into TDD with Python anyway.