In a recent post I mentioned that I started learning F#. Over the past few weeks I’ve really started falling in love with the language. Coincidentally, my team has been incorporating more test-driven development (TDD) into our process and as part of that training Roy Osherov’s TDD Kata 1 was mentioned. I immediately thought “Hey! Let me try doing that in F# and see how it goes!” I’ve run through the kata more than a few times now and I’m ready to share my experience with the world. (more…)
Indy Code Camp Notes, Part 4
This is part of a four part series of notes I took at Indy Code Camp on May 16, 2009. This year’s Code Camp consisted of five tracks each with five sessions. Track topics were SharePoint, SilverLight and WPF, Data Access, MIX highlights, and best practices. These notes are from the sessions I attended.
These notes are in no way intended to replace attending one of these talks if you have the chance.
Test Driven is Driving Me Insane!
Presented By: Dennis Burton
Dennis’s talk focused on road-blocks to effective Test Driven Development and some common, practical test patterns. My notes are a little sparse on this one since it was the last session of the day and my mind was wandering a bit ;) He had a lot of good examples that I wish I could remember a bit better.
Road-blocks To Effective Up-front Testing
- Management push-back
- “Double the code? Are you kidding?!”
- Project timeline impact due to code changes taking longer while tests are updated
- Test design issues
- Long-running tests – ideally each test should run in less than a second
- Long-setup time
- Fragile tests – more work is required to keep tests running when changes are made
- Data dependency issues – tests rely heavily on data specific data, often from a production environment
- Dummy Pattern – use when an object is needed only to help construct another object
- Stub Pattern – use when an object is needed to help construct another object and its state must be verified
- Mock Pattern – use when testing functionality functionality instead of specific data
- Spy Pattern – use to add validation to an object that does not implement the required validation. This is typically implemented as a wrapper class that passes values into the type being tested
- Test by feature rather than fixture
- Framework: Rhino.Mocks
- Reading: Working Effectively with Legacy Code
- Reading: XUnit Test Patterns