Last Friday's session was deemed helpful by the attendees, but it left a lot to be desired. Accordingly, this week's session will feature the following:
- A simpler problem (but still a real one that we encounter), with no code written for it.
- The problem visible to all even while code is being written. (Whiteboard)
- The skills we're focusing on visible to all. (Whiteboard)
When we retrieve date ranges from Ocean, they look like this:
They must be converted to a simple date format, like:
"1/2/2001 - 3/4/2011"
Rules for edge cases:
- Invalid string length - throw InvalidStringLength exception
- Invalid month or day - throw InvalidDateException, with calling out the invalid portion in the message
- Year not between 1700-Present + 1 - throw DateOutOfRangeException
- Range out of order (right side is before left side) - throw RangeOutOfOrderException
Curriculum topics covered
These sessions will cover all of the "foundation" TDD topics in our curriculum
- No production code without a test
- The developer has the habit of writing tests first
- The developer understands that different testing tools are useful at different levels (presentation, data, controller)
- The developer knows how to use mocks to test objects that have not yet been implemented, and can use at least one mocking tool
- Only enough code to make a test pass
- The developer understands the concept of "emergent design", and can apply it
- The developer does not create un-tested features
- Red. Green. Refactor. Don't skip any steps.
- The developer only creates a test when under green
- The developer only adds a new feature to production code under red
- The developer always refactors production code under green
- The developer looks for opportunities to refactor test code after adding each test
The curriculum mind-map is here
. You can download a copy of XMind here
- Good choice of problem - fast start.
- Good argument over using package-protected methods so we can test them.
- Demonstrated that up-front thinking/design is OK with TDD. (And that we can fail if we just blindly do TDD without some thought in advance.)
- Good corrections from the audience.
- Big Visible Focus and Problem statements (on whiteboard).
- Strict YAGNI-TDD does not work well.
- We didn't pick great method & variable names.
- Navigator role not done well.
- We didn't get through a simple problem.
- Collectively, we're not great at TDD.
- Cycle was too long for most (9m), too short for one.
- Frequency of Randori is too high (twice/week).
- Duration of Randori is too low (1h).
- Try leaving protected methods in the class so we can test them. The refactor step can decide if we need to make them private & move our tests to public methods later.
- Clarify roles (by writing them on the whiteboard): The driver will focus on the red-green-refactor cycle. The navigator will collect feedback from the audience to reduce the driver's distractions.
- Try a slightly shorter cycle next time - 7m.
- Focus on better method & variable names.
- Set up a randori once per week, for 1.5h instead of 2x1h