All the Perl that's Practical to Extract and Report

Failed tests as a shortcut to the zone

jplindstrom on 2003-04-02T11:29:01

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.

Cool!

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

Having a break

koschei on 2003-04-02T11:50:57

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 =)

Not Sure

chromatic on 2003-04-02T16:41:36

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, it's not so bad. Still, the idea of leaving one test failing and work undone overnight really bugs me. More artificially-flavored fruit-like drink, anyone?

Re:Not Sure

Matts on 2003-04-02T16:54:58

You could check in everything *but* the failing test. Leave that on your hard drive.

Re:Not Sure

chromatic on 2003-04-02T18:23:28

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.

Starting with a failing test

dws on 2003-04-02T16:48:38

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.

Re:Starting with a failing test

pdcawley on 2003-04-03T06:20:25

Beck also points out that this probably only really works if there's just one person/pair on the project.

Re:Starting with a failing test

merlyn on 2005-04-04T07:21:08

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}

GNU screen

mary.poppins on 2005-04-04T02:51:16

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.