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.
No comments:
Post a Comment