CF.Objective Notes -- The TDD List
July 01, 2012
The TDD List -- Bill Shelton
Testing:
Finding bugs in your code
Verification that your code works, does what it's supposed to do
TDD -- write the test FIRST, before you write the production code
aka "red green refactor"
TDD is a development method/process
Software testing is not
TDD does not find bugs.
It's good for -preventing- bugs
What goes into a test?
How do I know if my tests are OK? Do I have to test my test?
Models -- an abstraction that describes and simplifies complexity
Wireframes, storyboards, UML, todo's, back of napkin, etc.
Different people think differently
Outside-in, or inside-out?
Some people start from the UI and work "in"
other people start with the big picture, start with the code and build out from there
not necessarily good or bad, just different ways of approaching the problem
TDD 101
tools, patterns, and rhythm
Spike--
Taking a proof of concept and driving it all the way through...like a railroad spike.
1. Wrap "sketches" inside unit tests
2. As you gain understanding, factor code into local methods
3. Refine unit tests
4. Refactor code outside of unit tests
Test organization
Put your tests in a "test" directory
Create a similar structure to your app
Create a directory for test "fixtures"
-- choose expected/normal data first
-- choose data to find bugs
boolean -- true AND false
numeric - 1, 0, 0.1, min, max
date - past present, future
strings - "", NULL, big string, encodings - 0x03BC, μ, etc
Random data
etc
Be generous with test names
-- don't use "test1", "test2", use long, descriptive names
create an easy and clear way to run all tests
If your app uses a MVC architecture, your /test folder should have a similar structure
Mocking
make tests run faster
can do things like swap out the Twitter API with a fake "mock" object the test fast, etc.
Coverage
a measurement of how effective the tests are against your code
Want to know if tests are effective, is code executing the way I intended it to execute
Easier to track down untested code
Anti Patterns -- hints for refactoring (either tests, code, or both)
Brittle tests - tests that break a lot
Software is hard
software testing is equally hard
We want to make it easier
we want to keep our tests in isolation
Once they reach out to other sources they can be non deterministic
In a lab, we have a petrie dish, we don't want that petrie dish to be contaminated
We take a similar approach to testing
Books--
Test Driven - Lasse Koskella
The Way of Testivus
Intro to Software Testing (aka "the green book") -- Paul Ammann
Test and be happy!