What can I say about testing that has not been said? In fact, this morning for Zagaku we watched a video on testing that was another reorganization of the principles you’ve probably read or heard elsewhere in your journey to craftership. There are a few elements in PPP that did happen to define these test mindset commonalities in ways that I found unique and concise.

Intentionality

I like to think about the concept of programming with intention. Or, intentional programming. It clarifies the concept that our time developing consumes resources. Any extraneous effort made toward writing code directly affects our time & ability to write quality software.

Serendipity

I really enjoyed Martin’s use of serendipity to express the cohesion that arises in designs where TDD was used as a tool for building software from the ground up. He talks about both seredipitous decoupling and seredipitous architecture as consequencese of a test-first, test-early, test-often development workflow.

In an effort toward intentionality we should write at least two levels of test:

Low Level: Unit Test

  • written by the developer
  • written to specify the requirements of the smallest mechanisms in a program
  • ultimate documentation for an implementation
  • spawns Seredipitous decoupling Occurs as a result of writing test that are isolated. Test that are isolated when written before the code that makes them pass forces the components of a system to also be isolated or independent from the high-level functionality of a program. While programming, the act of decoupling and isolation is furthermore made trivial by the rest of a program’s components existing as their own independent machanisms. When I do regret a development effort, it’s usually because of frustration in testing new features after after the fact or even worse when the components require coupling to work correctly.

High Level: Acceptance Test

  • _written by team members that aren’t developers.
  • black box isolated customer use cases
  • can be written in plain text
  • ultimate documentation for a feature
  • spawns Serendipitous architecture As an added benefit of isolated test and black boxed acceptance test, where features This results in decoupling of modules and classes, such that a programs unique domains are composable but stand on their own, and with their own proof. When I do misstep on writing a test first, I always regret the resulting design of the system…

Fun and functional

This of course makes change easier and makes design a more organic or subconcious effort. Which I believe makes coding more enjoyable… and why shouldn’t it be less laborous and more intrinsically pleasurable for developers. I’ve come to genuinely believe that testing is directly linked to the amount of fun you have when programming. I still sometimes fail to heed my own advice on this, and