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.