I’m bettin’ u already got some code. If yer a geek in a substantial code base in an org w/more than a half-dozen other geeks, i’m bettin’ u already got a lot of code. In your team’s head, if not somewhere on an out-of-date piece of paper, there is a picture of "our code". I […]
The Rigorous Playpen Read More »
Companies spend a great deal of time and energy seeking to get their teams synchronized. Several forces motivate these efforts. It’s worth taking a second to look at these. One force: the belief that synchronization provides steering points. The notion here is that since we’ve just synchronized, now is a good time to react to
Sync Points Reduce Our Trade’s Effectiveness Read More »
If u think the semaphore mechanism in your library works, then test to the level of setting the semaphore. If u think it doesn’t work, then u need another library or o/s. Testing across threads is for people who are testing semaphores. If u think that your JSON transport works — from your UI’s perspective
What TDD Tests Prove Read More »
A Simple Optimization Problem Hey, it’s GeePaw! Got a little optimization issue for you. Let’s look at some code. It’s easy stuff, so I’ve just used pseudocode here. Take a look. The program starts by entering a loop that runs 50 times. Inside that loop, it calls the Read method. It then enters another nested
Optimizing A Program (And Programming) | Video Read More »
Continuing last night’s wobbly muse on graceful and awkward collaborators… In the light of day, I think I see four possible responses to the situation when your new code depends on an awkward collaborator or collaboration: Ignore it (possibly just for now). Write your test anyway and suffer the expense. This is a legitimate judgment,
Awkward and Graceful 2 (A Recovery) Read More »
Software Programs can be understood as (potentially huge) orchestras playing in concert. Depending on your level of abstraction, you might imagine systems, subsystems, layers, packages, objects, or even functions as the individual players. (Aside: Folks often make major distinctions in these abstractions, but to my touch, they feel all the same thing, just with ever
Awkward and Graceful Collaborators Read More »
Five Underplayed Premises Of Test-Driven Development (Transcript) Hey, it’s GeePaw! I’m here to tell you today about five underplayed premises of Test-Driven Development. These premises form the kind of fundament under which almost all TDD proceeds. And when I say that I’m a TDDer, I almost always mean I am operating inside the little ring
Five Underplayed Premises Of TDD | Video Read More »
Time, finally, for the steering premise, from the five underplayed TDD premises. The steering premise says "tests & testability help steer design & development". What we’re saying here is that tests are first-class citizens in the mob of factors that shape our system, with a voice that counts, all the way through development. Think of
Underplayed: The Steering Premise In Depth Read More »
Today, let’s talk a little about the chaining premise, from five underplayed tdd premises. The chaining premise says "test a chain by testing its links". Like the other premises, it’s easy to make it pithy, but it has vast ramifications about when we’re doing TDD. When we talked about the money premise, I gave a
Underplayed: The Chain Premise In Depth Read More »
The judgment premise is one of five underplayed tdd premises. The judgment premise is simple to word and vast in its extent. It says, "tdd relies absolutely on individual humans using their human judgment." you might ask yourself, "what doesn’t rely on human judgment?" but there are lots and lots of activities that are entirely
Underplayed: The Judgment Premise In Depth Read More »
