Automated Acceptance Testing or FitNesse to Improve the Quality of Software

March 23 23:00 2011 by Nataliia Vasylyna Print This Article

The quality of the product is not in the least dependent on the actual documentation and thorough testing. I would like to highlight the issue of developing and testing software in general and using FitNesse environment in particular.

Intro

When people talk about testing the software they often involve testing performed after a fair amount of code is written, and there is a need to check “and whether it written what they wanted.”

It is clear that the code coverage with tests, the types and duration of the test depends on many factors, but in this case you should mention it on the unit tests and acceptance tests.

If unit testing usually completes the one who wrote a particular piece of code, acceptance testing, as a rule, completes the customer. And it all depends on how high are the customer’s requirements (and, importantly, how he is able to qualitatively test taking to the finished product).

So, the unit tests are usually automated to implement (once they are written and many times are sold in automatic mode).

And the acceptance tests usually are run slowly in manual mode and change constantly and very seldom recorded on paper.

For what all this talks about testing? Well-organized process of testing of software products ultimately will save money and time to resolve errors, and furthermore increase the profit from the good reputation of the company.

Problem definition

When explaining the importance of testing it usually makes a time-table for the exponential increase in the cost of error correction in software product depending on the stage of its detection.

But we can’t forget that the cost of testing, especially the manual is too high. So if we will have more than 4500 tests for the run (which is normal for the average project acceptance testing), then we will need more than 40 man-days for a single performance of such testing. And now imagine that we have found a bug, and after correcting this error will be re-drive 4500 test manually.

In addition to problems with tests in manual mode, there is a problem with the maintenance of records up to date.

It is necessary to ensure synchronization of the following documents: requirements, specifications, user interfaces, the specification tests and their implementation.

For the specification of user interfaces, there is a tendency that the documents eventually released from screen shots and design schemes to make it more robust to possible errors. But at the same time such documentation is illegible, and it becomes difficult to understand. It appears too many low-level scenarios (Use Cases) and it becomes hard to maintain. All this ultimately results in the fact that the developers disappears motivation to maintain documentation to date.

Specification tests are usually fully duplicate specification of user interfaces with specific names, numbers and strings in the Use Cases (scenarios). They are more concrete and specific than the specification of user interfaces. But still leave open the possibility for a free interpretation of the people that they reflected.
It is difficult to maintain the motivation of developers and managers to maintain documentation to date.
The ideal option would be, of course, the use of robots for manual test run and incorporate the results in the documentation…

But the era of such clever gizmos has not come yet, so we have to use other methods…

FitNesse introduction

I propose to consider FitNesse

FitNesse – is primarily a tool for collaborative software development.

FitNesse enables customers, testers and programmers to learn what should make their software and automatically compare it with what the software actually makes. FitNesse allows you to compare customer expectations with the result.

FitNesse – a tool for testing software.
You can jointly determine AcceptanceTests – web pages containing simple tables of inputs and expected outputs. Run these tests and see results.

FitNesse – a wiki.
You can easily create and edit pages.

FIT (“Framework for Integrated Testing“) is the kernel, which actually treats each table FitNesse, using FixtureCode, referring to this table. It developed by Ward Cunningham (Ward Cunningham) as an extension of the medium xUnit and supports most modern programming languages (. Net, Java, Python, Ruby, C + +, …)

FIT + Wiki + Web Server = FitNesse

In addition to the FIT today there is support for technology SLIM, about which you can read more on the website of the product.
Possible to give an example of how looks fixture code, a table for the test and the result of environment work.

Example

Here is an example fixture code to test some applications in C #:
using System;
using System.Collections.Generic;
using System.Text;
using Ranorex;
namespace NetFit
{
public class AddVIPTest : fit.ColumnFixture
{
///
/// UI Repository instance for VIP Application
///
private VIPRepo repo = VIPRepo.Instance;
private string gender;
private string lastName;
private string firstName;
///
/// Property for FirstName parameter.
/// By setting the property Ranorex directly clicks
/// the text box and simulates the keyboard events
/// Returns the current text value of the text box.
///
public string FirstName
{
set
{
this.firstName = value;
repo.VIPApplication.FirstName.Click();
Ranorex.Keyboard.Press(firstName);
}
get
{
return repo.VIPApplication.FirstName.TextValue;
}
}
///
/// Property for FirstName parameter.
/// By setting the property Ranorex directly clicks
/// the text box and simulates the keyboard events
/// Returns the current text value of the text box.
///
public string LastName
{
set
{
this.lastName = value;
repo.VIPApplication.LastName.Click();
Ranorex.Keyboard.Press(lastName);
}
get
{
return repo.VIPApplication.LastName.TextValue;
}
}
///
/// Property for Gender parameter.
/// Depending on the given value Ranorex selects
/// the right radio button.
/// Returns the currently selected gender
///
public string Gender
{
set
{
gender = value;
if (gender.Equals(“Female”))
repo.VIPApplication.Gender.Female.Click();
else if (gender.Equals(“Male”))
repo.VIPApplication.Gender.Male.Click();
}
get
{
if (repo.VIPApplication.Gender.Female.Checked)
return “Female”;
else
return “Male”;
}
}
/// Method is used to simulate a click on
/// specified button.
///
///
/// Specifies the label of the button to press
///
public void Action(string button)
{
repo.VIPApplication.Self.FindChild(button).Click();
}
///
///
/// Returns the current text value of
/// the status bar.
///
public string ValidateStatusBox()
{
return repo.VIPApplication.StatusBar.TextValue;
}
}

Here is the table for Test Case for FitNesse:

And this is how looks the result of working of this test

:
Using FitNesse we can create test kits, which greatly simplify the acceptance testing of software. In addition, as FitNesse is a WiKi, then in one environment, you can store and maintain up to date all of the documentation on the project with reference to a test run as a module, and acceptance.