Exploration Through ExampleExample-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick
|
Thu, 08 Apr 2004Part of a series on FIT extensions and stylistic tricks. Here are two tests with identical contents (exact same words). Which do you prefer?
I prefer the second. If I want a quick idea of what the test's about, it's easy to scan the rows and just read the bold ones. It's comparatively hard to figure out what's going on if the steps in the test don't stand out from the checks. Other people might use color to distinguish the two types of rows. I find font changes less distracting than color changes. (As you can tell from this page or my main page, I'm a pretty colorless person.) A test is two things: an example of use and a check of correct results. I've always been bothered when I can't see the examples for the checks, and I've gone to silly lengths at times to keep them separate. Here's a test written in Ruby: def test_a_normal_day start_background_job assert_states([@misc], []) start 'stqe' assert_states([@stqe], [@misc]) start 'timeclock' assert_states([@timeclock], [@misc, @stqe]) pause_without_resumption assert_states([], [@timeclock, @misc, @stqe]) I don't go this far as a rule, but I wanted to talk about these tests with my Customer. This format let us step through the commands one by one. For each, I'd translate the assertion into human language. She didn't have to pay attention to anything on the right. |
|