The acronym stands for:

• Z – Zero
• O – One
• M – Many (or More complex)
• B – Boundary Behaviors
• I – Interface definition
• E – Exercise Exceptional behavior
• S – Simple Scenarios, Simple Solutions

“As the tests get more specific, the code gets more generic.”

… and “here’s the list of transformations” (47m53s):

So what are these transformations? Perhaps we can make a list of them:

1. ({}–>nil) no code at all->code that employs nil
2. (nil->constant)
3. (constant->constant+) a simple constant to a more complex constant
4. (constant->scalar) replacing a constant with a variable or an argument
5. (statement->statements) adding more unconditional statements.
6. (unconditional->if) splitting the execution path
7. (scalar->array)
8. (array->container)
9. (statement->recursion)
10. (if->while)
11. (expression->function) replacing an expression with a function or algorithm
12. (variable->assignment) replacing the value of a variable.

There are likely others.

… and, the process:

If we accept the Priority Premise, then we should amend the typical red-green-refactor process of TDD with the following provision:

• When passing a test, prefer higher priority [simpler] transformations.
• When posing a test choose one that can be passed with higher priority [simpler] transformations.
• When an implementation seems to require a low priority transformation, backtrack to see if there is a simpler test to pass.

( Source: https://www.youtube.com/ )

First make it work (get tests to pass).
Then make it right (clean it).
Then make it fast. (if it needs it).

Uncle Bob (via How to convince ‘performance guys’ to Clean Code – Google Groups )

Meszaros uses the term Test Double as the generic term for any kind of pretend object used in place of a real object for testing purposes. The name comes from the notion of a Stunt Double in movies. (…) Meszaros then defined four particular kinds of double:

• Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
• Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
• Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ‘sent’, or maybe only how many messages it ‘sent’.
• Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

The classical TDD style is to use real objects if possible and a double if it’s awkward to use the real thing. So a classical TDDer would use a real warehouse and a double for the mail service. The kind of double doesn’t really matter that much.

A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior. In this case for both the warehouse and the mail service.