Test-Driven Development Guided by ZOMBIES | Agile Alliance 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
Uncle Bob Martin walks through the “Prime Factors” kata in Java (29m06s) to illustrate the concept of Transformation Priority Premise as a way to address the common complaint about TDD: the brainlessness “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: ({}–>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....
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 )
Mocks Aren’t Stubs 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)....