Muses

TDD Pro-Tip: Prevent complex test data from spiraling out of control by going to builder & custom comparator early on. The push-to-small, coupled with SOLID, coupled with things like third normal form, all lead us to a place of wanting to compose domain objects into potentially very rich dependency graphs. A card in a address-tracking subsystem sounds at first blush like a class with about 5 simple strings in it, and we certainly start there when we first approach it.

TDD Pro-Tip: TDD and refactoring are permanently intertwined activities, neither of which can be grasped all at once, so start learning how to write tests at the same time you’re learning how to change code w/o adding bugs to it. Some activities are what I think of as "life games". The better you get at it, the more there is to learn. I call them games, cuz my first two noticed experiences of this were in the games of pool

TDD Pro-Tip: remember who works for who, and shape your tools to your hand, not your hand to your tools. (Btw, these tips are in no particular order. If you want to know the truth, i’m musing them as I do them. People always know more than they can say, and i’m no exception, but i’m digging at what I do over and over, and sharing it.) One difference I see over and over between noobs and olbs is the

TDD pro-tip: demeter chains are anti-microtestable. What is a demeter chain? It’s code where we talk to a collaborator’s collaborator. U can look up the origins of the name in your copious free time, but in regular code, it looks like this: x = a.b.c.d.e.f; each one of those dots is a link in a demeter chain out of whatever the object is that contains that assignment. A is our direct collaborator. We might have been passed her, or given