How can we be sure we are singing from the same page of music? – Fit in the key of C#
According to Jim Shore:
Great software requires collaboration and communication. During development, how can customers know that their programmers are producing the right thing? How can programmers know what the customers really want? How can testers know what's right and what's wrong? Getting these groups to communicate effectively and precisely should be a goal for teams creating great software.
Fit is a tool for enhancing communication and collaboration. Fit creates a feedback loop between customers and programmers. Fit allows customers and testers to use tools like Microsoft Office to give examples of how a program should behave--without being programmers themselves. Fit automatically checks those examples against the actual program, thus building a simple and powerful bridge between the business and software engineering worlds.
With Fit, customers can provide more guidance in development process by lending their subject matter expertise and imagination to the effort. The added visibility customers get into what is currently happening in a product allows them to steer projects the moment they begin to drift off-target.
With that so well stated, here is my initial run with Fit in C#. This article assumes that you have downloaded the Net platform implementation of fit.
Here are the steps we will use in creating and testing of Fit tables and fixtures in C#. First, create a new project in the fit solution and call it whatever you want. For this example, I called mine MarkTest.
The first fixture we’ll create in the MarkTest project derives from the ActionFixture class and is called ActionTest. This fixture interprets rows as a sequence of commands to be performed in order.
|
using fit;
namespace MarkTest { public class ActionTest : ActionFixture { private int number;
public void Number(int number) { this.number = number; }
public bool IsGreaterThanTwo() { return this.number > 2; } } } |
Fit works with HTML documents. Those documents include tables which are interpreted by fixtures. For this example, we will place our test tables in a HTML doc called MarkInput.html.
Here is the test table for the ActionTest fixture:
|
fit.ActionFixture |
||
|
start |
MarkTest.ActionTest |
|
|
enter |
number |
2 |
|
check |
IsGreaterThanTwo |
false |
|
enter |
number |
3 |
|
check |
IsGreaterThanTwo |
true |
A few things of interest, the first row names the fit.ActionFixture object. The second row has the start keyword and the MarkTest.ActionTest fixture class name. The ActionFixture interprets tables for which the first column contains one of a small number of commands. Subsequent columns contain values interpreted by the particular command. If you look at the ActionFixture base class you will see that the start, enter, and check key words have corresponding methods of the same name that parse the text from the same row’s cells and apply them to the ActionTest fixture above.
Next, we’ll create a Column Fixture object. The ColumnFixture object maps columns in the test data to fields or methods of its subclasses.
|
using fit;
namespace MarkTest { public class ColumnTest : ColumnFixture { public int FirstNumber; public int SecondNumber; public int ThirdNumber;
public ColumnTest() {}
public int TotalNumber() { return FirstNumber + SecondNumber + ThirdNumber; } } }
|
Note that the member variables are public. Since fixtures are test code, we want to expose these members publicly, as you will see in the test table. Normally, if we wanted to expose the FirstNumber, SecondNumber, and ThirdNumber variables we would create public properties for the private variables.
Here is the test table for this fixture:
|
MarkTest.ColumnTest |
|||
|
FirstNumber |
SecondNumber |
ThirdNumber |
TotalNumber() |
|
10 |
2 |
3 |
15 |
As you can see, the column headers match the fixture members.
Finally, we will look at the RowFixture. A RowFixture tests that you get back exactly the set of records that you expect to be returned from a query. For this, I need an object to implement for the testing of a RowFixture. Since I love books, how about a book object of some kind? Let’s call it Book. Pretty creative huh.
|
namespace MarkTest { public class Book { public int id = 0; public string title = null;
public Book(int id, string title) { this.id = id; this.title = title; }
public string GetBookTitle() { return this.title; } } }
|
Next, I created the fixture for the implementation code.
|
using System; using fit;
namespace MarkTest { public class RowTest : RowFixture { public override Type getTargetClass() { return typeof(MarkTest.Book); }
public override object[] query() { Book[] books = new Book[3]; books[0] = new Book(1,"First Book"); books[1] = new Book(2,"Second Book"); books[2] = new Book(3,"Third Book");
return books; } } } |
Here is the test table for the RowFixture:
|
MarkTest.RowTest |
|
|
id |
title |
|
1 |
First Book |
|
2 |
Second Book |
|
3 |
Third Book |
You will note that this time, the table column headers correspond to members in the Book object. This is due to the use of the instances of the Book class in the fixture. The query method in the fixture creates and returns an object array of type of Book. The RowFixture base class takes the object array and essentially checks that the input from the table matches the output from the RowTest fixture query.
I must admit that I am bothered by the fact that the Book object must expose the id and title members publicly. This is due to the ColumnFixture class, from which the RowFixture derives, which is looking for two types of class members characterized in the table column headers: (1) a field which is represented by a string in the fixture class (such as “id” or “title”) or (2) a method which displays a string appended with set of parentheses (“Id()” or “Title()”). In the java world, class members are exposed by “getter” and “setter” methods. This can be done in .Net but the common convention is to create public properties for the private members and expose them to the outside world via those properties. In any event, we used public members for this example.
Now, after rebuilding the solution to make sure no compilation errors exist, I invoke the runFile command to test the input tables. The standard Fit runner takes a single HTML file, processes it, and outputs the result to a different file.
Here is the usage of the runFile command: runFile input-file output-file [fixture-dir].
The input-file is the HTML file with the test tables, in this example the MarkInput.html file. The output-file is the feedback file, in this example the MarkOutput.html file. The fixture-dir is the directory containing your fixture DLL, in this example the MarkTest.dll file. Note that in the above example the fixture directory is a “.
Here are the contents of the MarkOutput.html file:
|
fit.ActionFixture |
||
|
start |
MarkTest.ActionTest |
|
|
enter |
number |
2 |
|
check |
IsGreaterThanTwo |
false |
|
enter |
number |
3 |
|
check |
IsGreaterThanTwo |
true |
|
MarkTest.ColumnTest |
|||
|
FirstNumber |
SecondNumber |
ThirdNumber |
TotalNumber() |
|
10 |
2 |
3 |
15 |
|
MarkTest.RowTest |
|
|
id |
title |
|
1 |
First Book |
|
2 |
Second Book |
|
3 |
Third Book |
In this case, the software is reporting the correct results for all the cases, so Fit has colored the table cells green. If the software reports the wrong result, Fit will color the table cells red. For more info on the color coding of the output-file, go here.
In summary, fit is a tool for enhancing communication and collaboration primarily between the developer and the software customer. This example, I hope, has provided a quick and dirty overview of how to do this in C#.