Randori Sessions‎ > ‎

Foundations Take 2: Date Translator

posted Jan 8, 2011, 3:53 PM by Erik Przekop   [ updated Jan 10, 2011, 10:08 AM ]

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)

The Problem
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).
Do Different:
  • 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