Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jplindstrom (594)

  (email not shown publicly)

Journal of jplindstrom (594)

Wednesday April 02, 2003
06:29 AM

Failed tests as a shortcut to the zone

[ #11400 ]

Recently I read (don't remember where, probably on the XP list) of someone who used to keep a failed unit test at the end of the day. The next day, it's obvious where you stopped the previous day, and it's obvious where you need to start working.

Usually I leave everything checked in and the tests at 100%, but Monday afternoon I tried the "failing" approach. After a complete day away from the code (project management training) it actually worked according to plan this morning. And after the first problem was solved and the tests back at 100%, I was up to speed on the coding and the problem domain.


Now I can perhaps stop writing myself post-it notes for the next day :)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Another good thing about it is that you get 16 hours (assuming 5pm-9am) of not looking at the code.

    You come in the next morning and can approach the code with a fresher outlook. And can often solve it instantly =)

      ---ict / Spoon
  • Not Sure (Score:2, Informative)

    Allowing known failures is a very slippery slope. Like bugs, test failures should be an exceptional thing.

    If you're doing XP, your engineering tasks should be short enough that you don't have to leave them overnight. If they're that large or that complex or things are going that poorly one afternoon, split them or just start over in the morning. The further you stray from a checkin, the less feedback the rest of the team has from your code.

    If you're not doing (or aren't trying to do) full-blown XP

    • You could check in everything *but* the failing test. Leave that on your hard drive.
      • Great minds -- that occurred to me right after posting. :) Since getting started is the hardest part, fixing a simple, failing test might have jump-start the day.

  • Kent Beck advises this in the back of his book on Test Driven Development. He got the idea from Richard Gabriel, who adopted it from advice often given to writers: Stop a writing session when the dramatic tension is nearly, but not completely, resolved. The mind loves resolution. Without it, your subconscious will continue to churn overnight, and when you pick things up in the morning, you'll have better ideas for how to resolve the tension, and this puts you right back into flow.
    • Beck also points out that this probably only really works if there's just one person/pair on the project.
      • Beck also points out that this probably only really works if there's just one person/pair on the project.
        On the contrary, it probably works ideally well if you're in a pair, and you leave a bug to be fixed overnight, but then don't come in the next day. {grin}
        • Randal L. Schwartz
        • Stonehenge
  • I use a very long-lived GNU screen session. At the end of the day, I leave under the cursor in my editor a roughly one-sentence description of what I'm doing.

    This way, when I come back to the problem, I've still got all my editors and shells set up, with their histories intact.