2012/08/14

That Conference: Testing Code From The Pit Of Despair

This session was presented by Phil Japikse.

  • http://www.telerik.com/zerotoagile for a podcast
  • Legacy Code == any code not under test, has a high technical debt, is icky
  • If the code is working and nobody asks you to change it, why change it?
  • Why change code
    • Killing bugs
    • Adding Features
    • Optimize Resources
    • Removing FUD
  • Make one change at a time
    • Fix or add just one thing
    • Test after every change
    • Commit after every passing test
  • Tools of the trade
    • TDD
      • Building up of the Lego blocks of code
      • Inside-out building
    • BDD
      • Don’t start with individual pieces to build the whole
      • Outside-in building
    • Mocking
      • Fakes, Stubs, and Mocks
      • Fakes have working implementations. They’re Hardcoded, not suitable for production
      • Stubs provide canned answers
      • Mocks are pre-programmed with expectations. Essentially creating a specification. They also record behavior
    • Dependency Inversion
    • UI Testing
      • Typically Manual
      • Often tested by customers
      • Tools becoming better
  • Testing and Refactoring
    • Be save; if you don’t touch the code it won’t break
    • Safety Blanket: Integration tests
    • Code Isolation and Refactoring
      • find a change point
        • Finding the point that breaks
      • create a seam
        • the weakest link of the system/class/method
        • use Dependency Injection
        • use commercial mocking
      • add a new test
        • Use test-eventually style
      • refactor
        • Extract Methods
        • Reduce Complexity
        • DRY
        • SOLID
      • Make sure you’re actually isolated
        • Continue to drill down
        • If code is self documenting, we don’t need as many code comments
      • Fix the target issue
        • Code is isolated, tests are in place, switch to T/BDD
        • It’s turtles all the way down
  • Test/Behavior Driven Development
    • Write a failing test
    • Make the test pass
    • Refactor: Remove magic code; add use cases
Post a Comment