Here are the notes from my lightning talk at PHPSW on May 16, 2012.

Victorious TDD

  • Victorious TDD
    • The Great Equaliser
      • Rainforest Hut
        • Imagine the problem, quickly execute the solution
      • Tree House
        • Ancestral knowledge and practice, probably done before
      • Burj
        • Approach without blueprints, a contract to build the structure to, and it will fail
        • Others may attempt modifications, but will not know what standards you constructed it to
    • Good
      • The code it produces is less buggy
      • TDD helps you learn, understand, and internalise the key principles of good modular design
        • code API use is specified by tests before coding
        • simplifies design, encourages decoupling, inversion of control
          • forces good architecture, better internal APIs
      • Makes collaboration easier and more efficient
      • Inspires confidence, especially for refactoring
        • Easier, harnessed bug fixing
        • Tests form living documentation and real code-use examples
    • Bad
      • It does increase time at the start of a project
      • You sometimes have to mock a lot of things, or things that are difficult to mock. It's beneficial in the long term, but painful right now
      • Dogmatic TDD doesn't help anybody!
      • It doesn't suit every problem
        • Graphics, GUIs
      • COVERAGE IS NOT GOD!
        • bug count is God
    • Principles
      • KISS
        • complex code is difficult to test
      • DRY
        • it happens
        • safety of refactoring ensured by tests
    • But every project needs tests
      • How
        • Write a failing test
        • Verify
        • Pass
        • Run all tests
        • Refactor
        • Repeat
      • Test Driven Development by Kent Beck
        • Rediscovery
          • The original description of TDD was in an ancient book about programming. It said you take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output. After I'd written the first xUnit framework in Smalltalk I remembered reading this and tried it out. That was the origin of TDD for me. When describing TDD to older programmers, I often hear, "Of course. How else could you program?" Therefore I refer to my role as "rediscovering" TDD.
      • Examples
        • JUnit
        • Spring
        • Eclipse
        • All Ruby code!
    • Not going to tell you every project should be test driven
      • Everything should be tested
        • before or after?
        • it's more difficult afterwards
      • Would Facebook have been successful if it had used TDD / BDD from the very beginning?
        • We have a lot of unit tests at Facebook. In general, the right amount of unit testing can save you time. If you are too obsessive about it you end up complicating the hell out of your code just to make sure every line is testable, and if you don't do enough of it you waste endless hours tracking down bugs that you should have caught right when you wrote them. Finding the right balance between the two may depend to some extent on your desired speed/quality trade-off, but largely that's misleading: many things that improve quality also improve speed of development.
      • F-35 Joint Strike Stealth Fighter - Coding Standard Documentation, C++
        • USA - US$323 development and procurement
        • Fleet - US$1.51 trillion over 50 years for 2,443 planes
        • ~3/4 US$1B per plane over operational lifetime
        • THEY MUST TEST
        • for complex code, comparing output with known test cases can decrease development time and bugs
          • Minimise
            • code size
            • complexity
            • static path content/cyclomatic complexity - the number of routes through a piece of code
              • written for a computer, but maintained by a human