Today, we’re going to continue our ParkCalc automation excursion. We will take a closer look on the second test in the provided test examples, the keyword-driven format, and see how we can improve it. Please note that I added an update to the previous blog entry showing that we can improve the test even more by extracting the date ranger into meaningfully named variables – just as Dale Emery did in his article Writing Maintainable Automated Acceptance Tests.

There is one small change I made to the tests since yesterday. This includes a proper state of the documentation. The Documentation lines in the functional.txt and resource.txt got an update to reflect what we’re doing there. You can inspect the source tree after this small change here.

Before we continue with the keyword-driven test, we should name it differently as calc2.txt. Since it contains a short-term parking test, let’s rename it to reflect this.

git mv keyword-driven/calc2.txt keyword-driven/short-term.txt

As before, run the test, and when it passes, we can commit it back to the repository.

The initial test is called “Basic Test”. I don’t like it, as it doesn’t reflect it’s intention, so we’re going to fix that first. The test seems to calculate a the costs for the first day, so the name First Day is obvious enough for me.

First Day

While the test executes, I review the procedures. I notice that I may extract some portions to a common setup and a common tear down before developing even more tests. Let’s do this first.

Suite Setup     Open ParkCalc
Test Setup      Input Parking Lot  Short-Term Parking
Suite Teardown  Close Browser

Note that I extracted the common Short-Term parking lot for this test into a Test Setup function, so that the proper parking lot is picked from the drop-down list each time. If there is something broken in the application selecting the wrong parking lot, I might get failing tests, since the parking lot was the one picked by the application. So, I avoid this by picking the proper parking lot every time. After this refactoring the First Day test becomes pretty short:

First Day
    Input Entry Date  12/31/2010  12:00  AM
    Input Leaving Date  01/01/2011  12:00  AM 
    Calculated Cost Should Be  $ 28.00

As before, when this test passes, I check back with the oracle whether the mentioned costs are correct, only to find out that there is a daily maximum of $ 24 instead of the $ 28 dollars. So, I change that, run the tests to see them fail, and submit my changes to the repository. The results can be seen here.

As before with the data-driven tests, I now start to express the business rules in more and tests. The structure I started with will contain one file with tests for each selected parking lot. For now, let’s finish the short-term parking first. At this point I decide that a test for the first hour, the first hour plus an additional hour, three hours, and twelve plus a half hour would be relevant tests. So, I add these:

First Hour
    Input Entry Date  05/04/2010  12:00  AM
    Input Leaving Date  05/04/2010  12:59  AM 
    Calculated Cost Should Be  $ 2.00

One And An Additional Half Hour
    Input Entry Date  05/04/2010  12:00  AM
    Input Leaving Date  05/04/2010  01:29  AM 
    Calculated Cost Should Be  $ 3.00

Three Hours
    Input Entry Date  05/04/2010  12:00  AM
    Input Leaving Date  05/04/2010  03:00  AM 
    Calculated Cost Should Be  $ 6.00

Twelve And A Half Hour
    Input Entry Date  05/04/2010  12:00  AM
    Input Leaving Date  05/04/2010  12:29  PM 
    Calculated Cost Should Be  $ 24.00

While adding the last test, I notice that it expresses the same business rule as my initial “First Day” test. In order to keep my test suite as small as possible, I decide to get rid of the First Day test completely. After exercising the suite, I check it back in into the repository. The sources can be found here.

In the same sense I create further tests for Valet, Economy, Long-Term Garage and Long-Term Surface parking. The results can be inspected here.

Taking a short breathe, I notice that I didn’t need to tough the resource.txt file for implementing theses tests at all. We will look back on this in a follow-up entry with a brief reflection and discussion.