Shulou(Shulou.com)06/03 Report--

I. Introduction

Fitnesse is an acceptance testing framework in standard parlance, so forget about these seemingly "tall" nouns. See how it describes itself. On the first page of the manual document, four descriptions are defined: 1. is a software development collaboration tool;2. is a software testing tool;3. is a wiki;4. is a webserver.

Start with the most operational features: a webserver, which is definitely web-accessible, is a website; a wiki, which is more specific. A Wiki is an encyclopedic site, usually designed to introduce a variety of knowledge. So fitnesse is similar and can be browsed to get the information we need. Of course, this information does not come out of thin air. We record it ourselves, and often it is not recorded by one person. That is to say, everyone can enter their own content, so as a forum site may not be impossible. Fitnesse security permissions and logs are weak, only to see the last modified content, which parts have been modified, who modified, modified several times, etc., can not be found, but this is not its focus. To be able to let everyone send information together and browse information together will also achieve the purpose of development cooperation, so although it is abstract, it is actually very simple.

So far, definitions 1, 3, and 4 are clear, so it doesn't seem to be any different from a normal site, and the key and interesting thing is that definition 2-is a testing tool. How does a site become a testing tool? There are actually two types of pages in fitnesse (operationally more than two, logically two). One is called static pages, which are just plain html text. The other is called an execution page, characterized by a button that can be executed (some pages are test buttons, some pages are suite buttons, which will be described in depth later). We can modify the properties of a page to indicate whether this page is an ordinary page or an executable page.

II. Implementation Principle

How are executable pages executed? In fact, when we click this button, fitnesse automatically launches 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 us (default is two types, fit and slim, theoretically you can customize the extension, I haven't tried it yet, because it is enough now);{class name} {method name} where does it come from? The answer is the tables on the page, so tables are a key element of fitnesse, and the next article is devoted to tables.

III. Advantages

Being able to think of a way to combine descriptive text with execution is what I admire most about the original creators of this tool. According to experience, the most likely reason for project failure is that information transmission is not smooth. In the traditional waterfall development model, when the requirements are transmitted from the user to the developer, they often go wrong, which leads to partial rework or even complete rework when the product is close to completion. It is strange that the project does not fail. In agile mode, the emphasis is on communication and collaboration. Requirements changes need to be communicated to developers quickly and accurately. Without a doubt, phone calls are the fastest, meetings are second, email notifications are second, document changes are the slowest and least effective, and they happen to be the most used. Why is that? Because the first few ways are not good to leave evidence, not good to file, not good to "brag" to others (for example, how standardized our management is, passed XXX certification, passed XXX acceptance...). Of course, the first few kinds are not without shortcomings. They do have their own advantages and disadvantages. We will not discuss this here. We will only talk about document changes. Even if notifications (not only manual emails, but also version management tool alerts) are sent to everyone after a document change, I'm afraid the effect is questionable. Because the notification has no binding force, there is no guarantee that who reads it, how much it reads, and how much it understands. We all have this experience. For those boring template documents, especially long ones, it is really difficult to read seriously. Sometimes I'd rather call and ask what's going on than bother reading this. Even if you read it, it's hard to say whether everyone's understanding is consistent. Fitnesse's way of combining documentation and actions gives us the possibility to write not only what we want to accomplish, but also what the effect is, and to perform tests to verify that effect. This is acceptance testing. Whether everyone's understanding is correct and consistent is determined by the red and green bars of the test. Green is qualified, red is a problem (maybe the requirements are not suitable, maybe the test cases are not suitable, maybe the code has bugs, in short, see the red bar to remind everyone to find the reason together). That's where fitnesse's value lies, not just as an automated testing tool. There are many automated testing tools or frameworks, but it is valuable to have both communication tools and testing tools.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.