I. Introduction
According to the standard, fitnesse is an acceptance test framework. Let's see how it introduces itself. On the homepage of the Manual Document, four descriptions are defined: 1. A software development cooperation tool; 2. A software testing tool; 3. A wiki; 4. a webserver.
First, we should understand from the most operational features: a webserver, that is, it must be accessed through the web, it should be a website, and a wiki, which is more specific. Wiki is an encyclopedian site that generally aims to introduce a variety of knowledge. So fitnesse is similar. You can browse it to obtain the information we need. Of course, this information is not provided out of thin air. It is recorded by ourselves, and often not recorded by one. That is to say, you can enter content in the forum, so it is impossible to use it as a forum site. Fitnesse's security permissions and logs are weak. You can only find the last modified content, which parts have been modified, Who modified them, and how many times they have been modified, however, this is not its focus. This allows everyone to share information and browse information, which achieves the goal of development cooperation. Therefore, despite the abstraction, it is actually very simple.
So far, the definitions 1, 3, and 4 have all understood, so it seems that there is no difference with ordinary sites, the key and interesting thing is that definition 2 is a test tool. How does one site become a test tool? In fact, fitnesse has two types of pages (more than two types of operations, which can be regarded as two types of logic), one is static pages, which is completely common HTML text. The other is the execution page. The feature is that there is a button that can be executed on it (some pages are the test button, some pages are the suite button, which will be further introduced later ), you can modify the attributes of a page to indicate whether the page is a common page or an executable page.
II. Implementation Principle
How is an executable page executed? In fact, when we click this button, fitnesse automatically starts a Java command, Java-cp xxxx. jar; XXXX. Jar {test_system} {class name} {method name }. XXXX. jar needs to be specified; {test_system} needs to be defined by ourselves (the default is two types: fit and slim, which can be customized theoretically. I have not tried it yet, because it is enough now ); where does {class name} {method name} come from? The answer is the table on the page. Therefore, the table is a key factor in fitnesse. The next article focuses on the table.
Iii. Advantages
The combination of descriptive text and execution operations is what I admire most for the initial originality of this tool. Based on experience, the possible cause of project failure is that information transmission is not smooth. In the traditional waterfall development model, requests are often transmitted from users to developers, which leads to partial rework or even full rework when the product is close to the completion of development, the project does not fail. In agile mode, communication and collaboration are emphasized. Demand changes must be quickly and accurately communicated to developers. Undoubtedly, the number of calls is the fastest, followed by discussion in meetings, followed by email notifications, and document changes are the slowest and the most useful. Why? These methods are difficult to retain evidence, archive, and boast to others (for example, how standardized our management is, we have passed the xxx certification, passed XXX acceptance ......). Of course, the first few items do not have any disadvantages, but they do have their own advantages and disadvantages. If you do not discuss this, simply say that the document is changed. After the document is changed, even if the notification (the notification I mentioned here is not only a manual email, but also a version management tool Reminder) to everyone, I am afraid this effect is also doubtful. Because there is no binding force on the notification, it cannot be guaranteed whether the notification has been read, read, or understood. We also have this experience. It is really difficult to read boring template documents, especially long documents. Sometimes I 'd rather call to ask what's going on than read this. Even if you read it, it is hard to say whether your understanding is consistent. Fitnesse, a combination of documents and operations, makes it possible for us to specify not only what is to be done, but also what the effect is, you can also perform a test to verify the effect. This is the acceptance test (acceptence testing ). Whether your understanding is correct or consistent is determined by the red-green bar of the test. If it is green, it will pass the test. If it is red, there will be a problem (maybe the demand is not suitable, maybe the test case is not suitable, or the Code has bugs. In short, we will remind you to find the cause when you see the red bars ). In my opinion, this is exactly the value of fitnesse, rather than looking at it as an automated testing tool. There are many automated testing tools or frameworks, and the combination of communication tools and testing tools is very valuable.
Fitnesse Series 1