Test #1 has passed and we can cross it off on our test list:
|
# |
Description | Status |
|
1 |
Create PI (purchase invoice) with 1 line and check that total line amount is calculated right | Complete |
|
2 |
Create PI with multiple (2) lines and check that total line amount is calculated right | |
|
3 |
Create PI with multiple lines and check that doc. amount verification succeeds | |
|
4 |
Create PI with multiple lines and check that doc. amount verification fails |
And even though I want to push forward to get on with the next test (make it turn GREEN, son), I owe myself, and OK you too, a little bit more explanation to the second part of my previous post. Well, uhhh, actually, I have to confess, Bas, my TDD guru, gave me some small hint on this. And admittedly I had to face the fact that there was one thing in his presentation (and also Kent Beck's book) that I had neglected: triangulation.
Knowing myself I should have been aware it was still there on one of my internal lists, where I park things to-be-investigated. Being a graduate technical physicist, and former physics and match teacher, I surely am acquainted with geometric triangulation as a means for measuring distances indirectly. I still can recall my amazement when I read how Greek scientists in the olden days already had used this method for calculating the distance to the sun. But in the context of testing software I was not instantly grasping the meaning of triangulation. But actually it's not so difficult (and I was just a bit lazy). David Bernstein gives a good explaination here. Applying his words directly to my doings in Test #1:
… I’ll write a test for the simplest non-error case I can think of and return a hard coded value.
In my case I did let CalcDocAmount return the value 1 – the fake it version as a more generic implementation was not obvious; this is the first angle in geometric tirangulation
Then I’ll write another test case and see if I can figure out the algorithm at that point.
Well this is what I did when rewriting my first test code (i.e. PIwithOneLine using the RANDOM function to feed my "Line Amount" field), being the second angle in geometric triangulation, and leading to my (more) generic implementation of CalcDocAmount
This actually means that I had created two complementary test cases and my test list should have looked like this:
|
# |
Description | Status |
|
1a |
Create PI (purchase invoice) with 1 line, set line amount to 1 and check that total line amount is calculated right | Complete |
|
1b |
Create PI with 1 line, populate line amount with random value and check that total line amount is calculated right | Complete |
|
2 |
Create PI with multiple (2) lines and check that total line amount is calculated right | |
|
3 |
Create PI with multiple lines and check that doc. amount verification succeeds | |
|
4 |
Create PI with multiple lines and check that doc. amount verification fails |
Allez-y! GREEN, here we come.