FitNesse is a collaborative software testing tool that allows users to define acceptance tests using simple tables, enabling effective communication between customers, testers, and developers. It supports Test Driven Development (TDD) with advantages like open-source frameworks and automated testing, though it comes with a learning curve. The document outlines the functionalities, fixtures available, and steps to create and run test suites using FitNesse.

1. Fitnesse -- a beginners introduction

2. Manifesto for Agile Software Development Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

3. Acceptance Testing Basically black-box testing giving a high-level view of what the system can produce. Different from Unit-testing that focuses on what the application does internally E.g. Blackbox testing - FIT, FitNesse (A Wiki built over the FIT framework) Unit testing -- Junit, HTTPUnit etc Advantages: Easy for the user to describe the requirements themselves (no programming, just text). Assumption is that we are using an existing frameworks. Easy for the developer to glue the requirements to the business logic Tests are written before the code, so this approach supports TDD i.e Test Driven Development Inexpensive because the frameworks are open source, execution of the tests can be automated. The developer has a clear goal to achieve! Disadvantages: No capture & replay possible Learning curve to understand the framework. Curve steeper if we have to modify the framework

4. Fitnesse – What is it ? FitNesse is a tool for enhancing collaboration in software development. FitNesse enables customers, testers, and programmers to learn what their software should do, and to automatically compare that to what it actually does do. It compares customers' expectations to actual results. FitNesse is a software testing tool. From another perspective, FitNesse is a lightweight, open-source framework that makes it easy for software teams to: Collaboratively define AcceptanceTests -- web pages containing simple tables of inputs and expected outputs. Run those tests and see the results. FitNesse is a wiki. You can easily create and edit pages. FitNesse is a web server. It requires no configuration or setup. Just run it and then direct your browser to the machine where it is running.

5. How does it work

6. Fixture, what ?

7. Fixture code

8. Fixtures – What’s available ColumnFixture: maps columns in the test data to fields or methods; a new column fixture is created for each table that uses one. ActionFixture: executes the command in the first column start aClass: create an object of aClass to work with enter aMethod anArgument: invoke the method on the object press aMethod: invoke the method on the object (without parameters) check aFunction aValue: invoke the (parameterless) function and compare return value with the specified value RowFixture: invokes methods on the objects and compares the returned values to those in the table binds the columns to variables and methods by reflection. Executes the functions to get the result rows which will be checked. matches the expected and result rows and check the matches. marks missing and surplus rows

9. Fixtures – What’s available - contd TPF Fixture : Fixture developed in-house (Jake Dempsey) that can create a Sabre Session, execute commands on it and compare the responses to expected values. Other available fixtures : CommandLineFixture : to execute shell commands in multiple threads HtmlFixture : to examine and navigate html pages SummaryFixture : displays a summary of all tests on a pageTableFixture: lets you access the cells in a table by row and column TimedActionFixture : (like ActionFixture) additionally with visual feedback on how long certain functions take to execute JDBC Fixture :JDBC fixture makes it easy to manage tests on a test bed of databases, for example, to exercise an order processing system with sample data.

10. Creating and Running Test Suites … Steps :- Creating a Test Suite. Create a new Wiki and give it a name. This would be the name of your test suite. Set Actions Properties for this Wiki page to “Suite” and save it. Create more Wiki pages underneath the suite and name them. These would be the names for your tests. Set Actions Properties for this Wiki pages to “Test” and save them. Edit the test Wiki pages and put in your test code i.e test tables that access the fixtures you would have created for your projects. Run your tests by clicking the test button on the panel onto the left of the page. Results page will be displayed!

11. The Road Ahead … Start with defining test cases for Host using the TPF fixture. This fixture allows you to create OFEP, NOFEP Sabre sessions, run commands on them, compare results with expected values etc. Other groups in Sabre already using this. (Can be done by a DPM) A list of all commands currently allowed can be found under “Command Reference” on the Fitnesse Wiki Reuse and extend current fixtures to interface and interact with the application code. (Should be done by a developer) Update command reference and have a brief description on how the new fixture should be used. Samples to work from would be helpful. DPMs can use the new command reference and examples to create Acceptance tests.

12. Developer resources Fitnesse home page :- http://fitnesse.org/ Eclipse plugin for Fixtures :- http://fitrunner.sourceforge.net/index.html#usage Useful links http://weblogs.java.net/blog/wwake/archive/2005/06/fit_code_part_7.html http://today.java.net/pub/a/today/2005/11/22/fitnesse-testing-for-agile-web-development.html http://www.cafeaulait.org/slides/sdbestpractices2006/fitnesse/ http://www.linuxjournal.com/article/8482 Checkout http://10.19.64.215:8088/ our Fitnesse URL. Lots of documentation present there