CF.Objective Notes -- The TDD List

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!