Introducing DSL Adapter for Generic Fixture

DSL (Domain Specific Language) is used to define problems in a specific domain. DSL, off late has gained a lot of focus due to its readability and ease of use. It is much more expressive than general purpose programming language especially for test authors, business people and end users.

When I published my Generic Fixture, there was a very valid concern raised by some FitNesse users that since Generic Fixture lets testers write their tests without writing any Java code and exposes user’s class level details (such as constructors and methods) to testers it might not be very appealing to customer and business folks as it is to developers. That’s when I started dwelling into this issue. Initially I thought of providing a MS Excel macro that lets testers write their test in DSL and by running that macro it will produce class level tests suited for Generic Fixture. But I abandoned that macro idea because of my unfamiliarity with VB and also to avoid hassle of an extra step for testers. (what if testers are writing tests directly on Wiki page rather than MS Excel). Finally I decided upon providing a plug-in kind of extension to Generic Fixture that will let testers define their own high level customer centric language (DSL). This DSL adapter will contain information on how to map it to Java Class level details. They just have to define this mapping once for each domain and can make it part of the SetUp page to make it available to for all the test pages.

Continue reading

Advertisements

Jump Start FitNesse with Selenium using Generic Fixture

Download FitNesse

Go to http://fitnesse.org/FitNesseDevelopment.DownLoad and download the the latest fitnesse.jar. Create a directory c:\program files\fitnesse\. Copy the downloaded fitnesse.jar into directory c:\program files\fitnesse. fitnesse.jar is an executable jar file so just double click this file and it will install itself.

Download Selenium Remote Control (Selenium RC)

Go to http://selenium-rc.openqa.org/download.jsp and download the latest version (1.0.3 at the time of writing this page). Unpack the zip into c:\program files\selenium\ directory. Current version for Selenium-RC is 1.0.3 and these instructions are written assuming you are using this version.

Create a smart start script

Copy and paste following script into a file called run.vbs under the directory “C:\Program Files\selenium\selenium-server-1.0.3”. This script will start both FitNesse servers and Selenium remote control servers on their default ports 8000 and 4444 respectively. This script will ONLY start these processes if these processes are not running, so this script can be safely run any time.

PS: Please note that this script is starting Selenium in an experimental Proxy Injection Mode which lets you run your web test across multiple domains. If you don’t want to use this feature feel free to change this start script.

Continue reading

Introducing Generic Fixture for FitNesse

I have been using FitNesse (A wiki based integrated testing framework) for last few years to create automated integrated acceptance tests for my back end Java based and legacy C/C++ applications. It has helped us tremendously towards our efforts to adapt to Test Driven Development (TDD). FitNesse has really helped our development team to find & fix bugs much earlier and our QA team to validate them pretty quickly. For beginners I will recommend reading the documentation on its official web site http://fitnesse.org/ for information on downloading, installing and setting up FitNesse. FitNesse provides various “Test Table Styles” (or fixtures) to write your tests. Each Table/Fixture Style has its own usage and purpose.

For testing business logic in my back end applications I mostly used ColumnFixture, TableFixture and RowFixture for defining inputs and output data sets. All I needed to write was a thin adapter or mapper Java class that extends any of these fixtures. That thin adapter Java class just gets input data from wiki and use that data to make a call to my back end application. At the end of the call it just makes the result available for FitNesse to display on wiki page. This thin adapter class is fully Fixture aware and developer of this class must know how to map data between back end application and FitNesse front end wiki page.

So far so good no major complains here, it worked great for us.

But I found this requirement to write the thin fixture adapter class for each new transaction a little annoying and have always toyed with the idea of building a generic Table/Fixture, one that will not require a developer to understand and be aware of the various fixtures coding conventions. In other words a fixture/table style where testers can write acceptance tests without needing development support of writing fixture specific code for each new transaction.

That became the main driving force behind the thought of developing a Generic Fixture where you just drop your class in FitNesse’s class path, write your test tables in wiki and be ready to test without having to write a single line of Java code. This idea is simple enough to understand but not so simple to implement because of the complexity of Java classes. Each class is different, it can have various type of constructors and methods (even overloaded ones). Each method can be returning different type of values (or not returning at all if method is void). We have to define some rules of defining class names, constructors, method names and their return types on wiki test tables first.

Continue reading