Code Kata

Do you want to become really good at Test-Driven Development (TDD)?  Learning transformations is one of the best ways to get there.  Transformations provide a methodical approach to passing your tests while realizing a high-quality design. 

What Are Transformations

Transformations are the opposite of refactoring.  Refactoring changes (improves) the structure of the code without significantly changing its behavior, while transformations change the code to generalize behavior without significantly changing its structure. 

Applying Transformations to TDD

The common pattern for TDD is the Red - Green - Refactor cycle.  In the Red phase, we first write just enough of a unit test to demonstrate a failure.  Then in the Green phase, we write just enough production code to make the test pass.  But we should think of this phase not just as the Green phase, but as the Transform-to-Green phase.  That's because we use transformations to get the tests to pass. 

Transformations Defined

These are the 12 transformations that Bob Martin developed and prioritized to make TDD a little simpler and straighforward.  A clean architecture usually results when applying them in this order.

  1. Null
    When first creating a new function, start by doing nothing more than return null.
  2. Null to Constant
    Transforming null to a constant should be just enough to make your next test pass.  This could be any type of constant, such as a numeric, string, or an object — whichever value will cause your test to pass.
  3. Constant to Variable
    Changing a constant to a variable (or an argument) by itself does not alter behavior, but it is part of a sequence of transformations that enables other transformations.  Simply create a variable in place of a constant and assign its value.
  4. Add Computation
    This transformation is used to add computations or initialize variables, but can never change the state of an existing variable.  This may include adding predicates or any mathematical operation.
  5. Split Flow
    Here we add an if statement to split the flow of control into two (and only two) paths of execution.  This allows two or more values to pass the test — which was enabled by the Constant to Variable transformation.  Be sure to use the most general predicate that passes the test, i.e. use < or > as opposed to ==.
  6. Variable to Array
    After making your tests pass for one thing, you will eventually need to make them pass for more than one of those things.  This is where you want to transform your variable to an array to accommodate multiple occurrences of that one thing.
  7. Array to Container
    This is used to generalize an array to something more generic such as a list, queue, or stack.
  8. If to While
    This is used for a flow that has already been split and must now be repeated.  And since a for loop is special case of a while loop, you can usually transform directly to a for statement. This is often used following a Variable to Array transformation.
  9. Recurse
    To perform an operation over and over again, simply put it into a function and make the function call itself.
  10. Iterate
    This transformation is used when you want to repeat an operation, but do not want to use recursion.
  11. Assign
    Use this to change the state of a previously existing variable, but not to initialize a variable's initial state.
  12. Add Case
    This transformation is used when we have a split flow that we want to split further.  This occurs when we add an else to an existing if statement or a case to an existing switch statement.
3 Laws of Test-Driven Development

Following are the 3 laws that define the discipline of TDD.  By following these laws, along with the transformations above, you will be surprised how quickly and easily you realize a good solution to this problem.

  1. Write no production code except to pass a failing test.
  2. Write only enough of a test to demonstrate a failure.
  3. Write only enough production code to pass the test.