Utilizing your .NET Project's Automated Acceptance Tests on Crystal Reports - Part 1
page 3 of 7
by Eric Landes
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 25518/ 65

Utilizing Automated Acceptance Tests with Reports

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:













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.

View Entire Article

User Comments

No comments posted yet.

Product Spotlight
Product Spotlight 

Community Advice: ASP | SQL | XML | Regular Expressions | Windows

©Copyright 1998-2021 ASPAlliance.com  |  Page Processed at 2021-04-16 9:40:57 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search