Now that we have established the purpose of these articles,
let us discuss the theory behind Automated tests, and specifically what this article
expects of these tests. Then we will look at how we create our Automated
Acceptance testing. These theories are attributed to many folks, but Robert
Martin, is the specific inspiration for me. Ron Jeffries has also had an
impact.
We assume that you have your customer's co locate with the
team when writing these tests for each story. These tests are not the only
testing used for acceptance of the software, but they provide a reliable method
for defining customer specifications that can be executed against your code. We
should also release software into the wild, allowing the customers to run the latest
version of the software. The customer runs that software after you complete the
latest iteration. Do not expect to discard manual testing if you are new to
this concept. But having these tests should make your manual testing less
painful.
This article uses the fitnesse
testing framework to create our tests. We use fitnesse to allow business
customers to define their requirements in an Excel like manner.
Fitnesse is a front end to the Fit testing framework. Based
on the idea that many acceptance tests can be defined in an Excel style format,
Fitnesse allows end users to quickly write up tests. Once those tests are
created, developers can quickly hook up their business objects to these tests,
and run the tests. Running Fitnesse tests give the standard green red results.
So as an example, you might define your business logic to
calculate taxes. To write the test, a grid is created that gives the cost of
the product, the location sales tax, and the expected result. It might look
something like this:
|
Cost
|
Tax
|
Total
|
|
$10.00
|
5%
|
$10.50
|
|
$29.00
|
6.8%
|
$30.97
|
|
$1,002
|
7%
|
$1,072.14
|
In the table, the user defines what values go into cost, the
value in tax, and then the total they expect from this. The developer then
needs to hook their business logic up to place the value of cost, into their
object cost, and the tax percentage into their objects tax. Finally, the
developer runs the business logic to calculate the Total, and check if it equals
the expected total entered in the test.
