# Transformation Priority Premise

Transformation Priority Premise (TPP) is a programming approach developed by Robert C. Martin (Uncle Bob) as a refinement to make the process of test-driven development (TDD) easier and more effective for a computer programmer.
Transformation Priority Premise states that simpler transformations should be preferred:
   [...]Refactorings have counterparts called Transformations. Refactorings are simple operations that change the structure of code without changing its behavior. Transformations are simple operations that change the behavior of code. Transformations can be used as the sole means for passing the currently failing test in the red/green/refactor cycle. Transformations have a priority, or a preferred ordering, which if maintained, by the ordering of the tests, will prevent impasses, or long outages in the red/green/refactor cycle.
This approach facilitates the programmer doing the simplest possible thing for the purposes of test-driven development as they can explicitly refer to the list of transformations and favor the simpler transformations (from the top of the list) over those further down in the list in the first instance.
   The Transformation Priority Premise is a name given to the mental structure TDD’ers build up over time as to balance your code from being too specific, rather than generic. The idea is that with each example you add to the tests you move up the Transformation Priority list, making your code more generic, so able to handle more of the cases. In contrast, your tests, with more examples, become ever more specific and focused on the problem. So you start with a constant for your first test, for your next test you might change that constant to an “if” for the next step you might introduce a loop. Each time you’re moving up the priority premise. The aim of following this structure is to avoid Accidental Complication, and to add only to Essential Complication. Each step is the smallest possible change you can make to implement only the code required to implement the examples given in the test..

## The Transformations

* ( → nil) no code at all → code that employs nil
* (nil → constant)
* (constant → constant+) a simple constant to a more complex constant
* (constant → scalar) replacing a constant with a variable or an argument
* (statement → statements) adding more unconditional statements.
* (unconditional → if) splitting the execution path
* (scalar → array)
* (array → container)
* (statement → tail-recursion)
* (if → while)
* (statement → non-tail-recursion)
* (expression → function) replacing an expression with a function or algorithm
* (variable → assignment) replacing the value of a variable.
* (case) adding a case (or else) to an existing switch or if
Uncle Bob also explicitly stated: "There are likely others", and
   [I] think that the priority list is language specific... In Java, for example, we might move (if→while) and (variable→assignment) above (statement→tail-recursion) so that iteration is always preferred above recursion, and assignment is preferred above parameter passing ... because Java is not a functional language.

## How to use the Transformations in Practice

Ridlehoover clarifies that the Transformations help you pick which tests to write and in what order.
   [The Transformations] can actually help us pick which tests we should write in what order. For example, if we decide to write a test that requires us to add an if statement to our code, that test requires the “unconditional –> if” transformation. Knowing that, we can try to think of other tests that rely solely on transformations higher up the list. The ultimate reward is that by writing our tests using transformation priority order, we should not ever get to a point where one test causes us to rewrite an entire method.
Corey Haines provides a live coding demo (Roman Numerals Kata) where he solves a coding challenge utilising the Transformations.