Goals

• Write unit tests
• Think in terms of interfaces, inputs and outputs
• Red-green every test every time to ensure that the test is correct and implementation is correct
• Test one thing at a time
• Think of edge cases, unit tests only test the things that you think of
• Remember that test driving your application design in the long run is the most valuable part of test driven development

Play By Play

1. Create the test file first
2. First describe block is NameOfClass
3. Second describe block is [#.]nameOfMethod

• Hash for instance methods
• Dot for class methods

4. Start with initial test that expects null or an empty array just to validate the method interface

• This gives you time to think about possibly renaming the class or method without other complications

5. Run tests to see it fail
6. Get the correct failure

• uninitialized constant Foo or undefined method 'bar' for Foo:Class

7. Pass test by creating implementation file with the class and method
8. Delete interface test so it can be replaced with first real test
9. Write base case or simple case test context

• for example when the input is an empty array
• Describe the subproblem you are tackling before you tackle it

9. Write the it block

• Describe what you expect the method to do in words before writing the code

10. Fill in your test setup

• This includes instance initialization parameters, method inputs and stubbed dependencies
• Often

11. Run tests to see it fail

• Get the right failure every time before moving forward and lean on your pair to validate this
• Sometimes you want to slime your implementation code since test correctness is more important that implementation correctness, for example if your test expects the output 0 and your method already returns 0 then temporarily make it return something else to get a failure