Successful microtest TDD depends on our ability to solve a goldilocks challenge: when we test our code pieces, do we isolate them too much, too little, or just right? Finding the sweet spot will mean letting go of rulesets & purity. The five premises we've been over: value, judgment, correlation, steering, and pieces, guide us in a complicated dance of software design. At the center of that dance is our awareness of -- and our manipulation of -- "dependency", how one part of the code uses other parts of it. From the moment you wrote your first program, you produced a high-structure high-detail text that *depends* on the output of other high-structure high-detail text.


---


You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.

---

Send in a voice message: https://podcasters.spotify.com/pod/show/geepawhill/message

Twitter Mentions