FitNesse using series two

Decision table

There are several table styles available in FitNesse, as mentioned earlier. The table is the key to running the test. From the literal view. The table description describes a test example. From a run point of view, the table provides the package name, class name, method name, and parameters (in Java as an example) for the back-end code (called fixture in FitNesse).

First, the test system. The FitNesse offers two test systems: fit and slim. Different test systems are used, with different table styles and different code. So, first of all, decide which one to use. Fit is the default. is extended from the framework for Integrated Test tool.

Assuming that the old code is not taken into account, it is recommended to use slim. Because the slim is better in performance. And the code is easier to write.

To use slim, you need to add a line to the page:!define test_system {slim}. Usually placed at the top of the page

The following is a description of the class or jar package on which the code is run. The format is generally written like this:

!pathd:\software\eclipse\workspaces\mydemo\bin\ or

!pathd:\software\eclipse\workspaces\mydemo\libs\*.jar (assume that you do not specify a. jar. Then go find the. class file)

In last year's version number also need to add FitNesse own jar package:!pathd:\software\fitnesse-standalone.jar, but this year's version number. I found that I did not need this sentence.

The decision table is of this style:

My demo
Inputa	InputB	Exp?
1	2	3
8	9	17

This my demo is the class name of the code. You know that in most programming languages you do not agree with identifiers that contain spaces. It is certainly not possible to use my demo in the code.

FitNesse is actually doing this-capitalize each word and then connect it with the first letter. So the class name corresponding to the code is Mydemo. In this way, the fact that this is written in my demo, my demo, Mydemo effect is the same. But written Mydemo is not. This can only be converted into Mydemo, I think I made it clear. For the full name of the class (with the package name). That just can honestly according to the normal wording, such as: Com.calis.zjc.MyDemo, can not have spaces, or else to take the initiative to capitalize on the first letter is not correct.

The next line is the method name.

FitNesse is doing this--where the end is not, all think is the input method, no return value, the method name is the set+ first letter uppercase string. Other words.  The corresponding method names in the table above are: void Setinputa (...) , void Setinputb (...) , and the column at the end is the validation method, and no parameters have a return value. The corresponding method name is int exp (). Why is it that the return value type is int, which is actually not qualified. Whatever type is returned can be compared to the characters on the page. This is smarter (I don't see the source, but I expect to get the return value again. toString (), followed by the string on the page to do equals)

In summary: The corresponding code for the above table is:

public class Mydemo {private int a,b;public void Setinputa (int a) {this.a=a;} public void Setinputb (int b) {this.b=b;} public int exp () {return a+b;}}

When we set this page property to test, click that Testbutton, the system will find and load the class, and then run the corresponding method, namely: the first step setinputa (int a), A is 1. The second step is setinputb (int b), B is 2, and the third step exp Gets the return value 3 and the 3 in the table is more consistent, the line is green, the inconsistency is red, and then the second line ..., and then the end of the two test example run.

(Assuming that the table is not filled with integers, then the run assignment method throws an exception, which should also be noted)

Again, running a page is not just about writing a table. Be able to write other words completely. Does not affect the running result. So we are fully able to write a requirement statement, follow a form for verification, write a description of the use, and then write a table. Describe a flaw, and then follow a table ... In this way, the page becomes both a document and a running use case.

In short, let "text" be verified. Is the highlight of this tool.

FitNesse using series two