Getting our first two tests, test #1 and test #2, working (GREEN! … GREEN! … GREEN!), we successfully implemented the first part of our feature, i.e. the function CalcDocAmount, leaving us now with it's counterpart: the verification of the manually entered total amount of the document (invoice).
|
# |
Description | Status |
|
1a |
Create PI (purchase invoice) with 1 line 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 | Complete |
|
3 |
Create PI with multiple lines and check that doc. amount verification succeeds | In Progress |
|
4 |
Create PI with multiple lines and check that doc. amount verification fails |
So let us pick up the next test (test #3) and speed for GREEN! I guess by now you can also dream the RED/GREEN/REFACTOR mantra so we'll might as well increase our steps.
1. Write our test code
"Create PI with multiple lines …", it says, so let's C&P our PIwithTwoLines function and rewrite it to become SucceedingVerification:
SucceedingVerification()
// Create a purchase header
PurchHeader."Doc. Amount" := 3; //Mimic the manual input of the total doc. amount
PurchHeader.INSERT(TRUE);
// Create two purchase lines to the header
CreatePurchLine(PurchHeader."No.",10000,1);
CreatePurchLine(PurchHeader."No.",20000,2);
//Check if manually entered total doc. amount equals the line amounts
Assert.IsTrue(PurchHeader.VerifyDocAmount,'Verify Doc. Amount')
Indeed we will need a new boolean returning function VerifyDocAmount.
2. Compile test code
RED!
Sure, no Doc. Amount field exists on the Purchase Header table (38). So we know what to do to …
3. Implement just enough to compile
… but let's kill two birds with one stone (we did increase our step size, didn't we?) and also deal with VerifyDocAmount.
Close and save our Test Doc. Amount codeunit (60000) – without compiling it and design table 38, i.e. adding:
- Doc. Amount field
- VerifyDocAmount function returning a boolean:
VerifyDocAmount() Verified : Boolean
Does table 38 compile? Yes. GREEN. So we could go and compile our test codeunit (60000) and most probably see it fail (RED), but, you're right, we would take bigger steps, so we skip step 4 (Run test and see it fail) and adjust our VerifyDocAmount function more seriously, i.e. …
5. Implement … to make the test pass
VerifyDocAmount() Verified : Boolean
EXIT("Doc. Amount" = CalcDocAmount)
Compile? Yes. GREEN. OK …
Go, go, go, go, …
6. Run test and see it pass
YES … GREEN! We're getting more confident by the day, uhhh, test. [8-|]
7. Refactor
Anything to refactor? Looking at the production code … nope. Looking at the test code … yep, PIwithTwoLines and SucceedingVerification look very much alike, i.e. duplication of the code. We could definitely do something about this right now, but we'll put this on our to do list as we first would like to go for the next test (and there is something more to this that I want to get into later). So let's …
8. Repeat from top
Test #4 here we come, but first cross off the current test on our test list:
|
# |
Description | Status |
|
1a |
Create PI (purchase invoice) with 1 line 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 | Complete |
|
3 |
Create PI with multiple lines and check that doc. amount verification succeeds | Complete |
|
4 |
Create PI with multiple lines and check that doc. amount verification fails |