2010/01/15

Codemash: Software Design & Testability

This session was presented by Jeremy Miller

  • Testability & Design is not about mock objects/interfaces.  It’s about finding/removing/preventing defects.  Better partitioning or responsibilities.  Boils down to “Divide & Conquer”.
  • “I don’t code, I ship software”
    • Take advice from Mary Poppendieck about optimizing the whole of the project, not just the code.
  • Good Code vs. Bad Code
    • The quality of the code has a dramatic impact on how productive the developer can be.
  • Interesting quote from Michael Feathers: “I don’t care how good you think your design is.  If I can’t walk in and write a test for an arbitrary method of your in five minutes…”
  • First causes of good design
    • Feedback, Cycle Times, Batch Size
    • Orthogonality
      • Being able to focus on features independent of other features.
    • Reversibility
      • The ability to change a decision that’s been made about the code.
    • Understandability
      • Is the code readable and can be followed easily?
  • Writing Automated Tests
    • Set the system into a known state using known inputs
    • It has measurable outcomes
      • State based tests.  I.E. Calling a method to write a file results in a file actually being written.
      • Interaction based tests. I.E. Verifying that a method is actually called.
  • What makes tests better
    • Repeatable
      • Running the same test over and over always has the same result
    • Runs Fast
      • If you can’t run the test quickly, you won’t run them that often.
    • Easy to write
    • Easy to understand
      • If you can’t quickly and easily glance at the unit test to verify what the test is aimed at, it’s not easy to understand
  • Systems that are hard to test
    • invoicing rules engine
    • rules defined in an xml file
    • invoice data read from stored procedures
    • no seams in the application to break it apart.
  • How do I test
    • WorkflowProcessor
      • Basic workflow logic
      • State persisted to the database
      • Sent emails at various times
  • Things that are hard to test
    • The database
    • Active Directory
    • Web Services
    • Messaging
    • Windows Services
    • Remoting
    • SCF
    • WPF/WinForms
    • System.Web Namespace
    • External System
    • Chatty APIs
  • “Isolate the ugly stuff.  That essentially comes down to anything written by Microsoft”
  • Test small before testing big
    • Verifying that the pieces actually fit together
      • Start working on the pieces you know how they work.
      • It’s just the small pieces you’re working on, not the entire system as a whole.
    • Code from the bottom up…
      • start with the small pieces
    • …or from the top down
      • Use mock objects to flush out API and how things will fit together.
  • Talked about Dependency Injection (with a rather strange bias towards StructureMap. Gee…wonder why…).
  • Keep a short tail
    • Can you pull it off a shelf and work with it without pulling down/in extra classes.
    • Isolate the Churn
      • Isolate when there’s a lot of change.
Post a Comment