Nathan Ladd's wroclove.rb 2023 talk (March 31, 2023), interleaving the history of Test Bench with his personal history of learning TDD. Ladd recalls being a self-taught 90s kid who rushed everything (school, guitar, code), found early career success writing Linux device drivers in C, and thought he understood TDD until he started working with Scott Bellware in 2015. Walks through the origin of Test Bench: dissatisfaction with minitest's `must_equal`/`should_equal` ambiguity, lack of `refute_raises`, random ordering requiring the `i_suck_and_my_tests_are_order_dependent!` method, and the realization that tests are just procedures — so test files should be plain Ruby scripts. The initial DSL (assert, refute, context, test, plus later assert_raises/refute_raises) shipped on RubyGems on March 31, 2016. Describes a Herculean late-2018-through-2020 rewrite using strict TDD, Useful Objects, zero-compromise design principles, immediate correction of every mistake and all its downstream fallout, and git checkpoints via interactive rebasing — 'a little like lead climbing'. Work was derailed by substance abuse and a four-story balcony fall at the time of wroclove.rb 2019 that broke seven ribs, sternum, clavicle, femur, face/nose/skull (a Le Fort III fracture); Scott Bellware and Ethan Garofolo organized a morale video. Returning post-recovery, Ladd discovered that because Test Bench's DSL had to operate in isolation to test itself, the DSL could be included in any class — producing fixtures: self-testable test objects that compose like production code (e.g. a schema-equality fixture used inside a message-handler fixture in Eventide). Demonstrates a data-structure comparison fixture printing full context/attribute detail on both pass and fail. Argues TDD is about eliminating obstructions to understanding, that static types can't compose on top of themselves the way test objects can, and that 'practice doesn't make perfect — practice makes permanent'. Q&A: (1) clarifies 'fixture' vs Rails fixtures — traces the term to Kent Beck's 1989 Smalltalk xUnit writeup where a fixture was a behavioral testing device, regrets the ambiguity with Active Record YAML fixtures, uses the light-fixture metaphor; (2) on asserting collection properties, notes RSpec composable matchers are the common solution but recommends specialized fixtures (e.g. nokogiri+CSS-selector fixtures for XML), emphasizing Tell-Don't-Ask and building exactly the verification you need; (3) Scott Bellware elaborates that fixtures in Test Bench are just plain classes that include `TestBench::Fixture`, use the Introduce Explaining Variable refactoring to reduce everything to assert/refute on booleans, and avoid RSpec's elaborate matcher API.