Writing Advanced Generic Fixture Test Scripts (loops, conditions etc)

It’s been really long time since I wrote my last article on Generic Fixture and FitNesse. My projects kept me on my toes for most of the time but in between whatever time I got I was probably just too lethargic to shoot down a full post. However it doesn’t mean that I wasn’t developing and supporting Generic Fixture all this time. I made it a point to respond to each and every question that was asked in the comments section. I also gave ample hints on these features in few of my comments on my Blog.

So as the title suggests we are going to cover advanced test scripting on this post which means loops, conditions, branches, expressions, exception handling etc. Let me make it clear at this point that I am not recommending using these features in each and every test story because it will only make test stories a bit harder to read and maintain. It is best to handle these things in a helper class and you should deal with helper class though Generic Fixture.

However there are scenarios when it is unavoidable to encapsulate everything in helper classes and hence need of these advanced features in Generic Fixture. We are going to cover few of these scenarios in example section of these advanced scripts.

If you recall that Generic Fixture simply lets you execute all the public method of any Java class from FitNesse Wiki. So the obvious question that comes to anybody’s mind is how to do looping, branching etc from a method call. I took a cue from Apache JMeter software that lets you use a very useful utility called Bean Shell which is fully Java compatible scripting engine for evaluating data returned from JMeter test scripts. Let me just stress here that JMeter is an excellent tool for performance and load testing of Java applications and web portals. We use JMeter extensively in our projects for performance benchmarking.

Now coming back to Bean Shell (bsh), it’s becoming a top choice for Java scripting (not to be confused with JavaScript). It is being used by Apache, Sun, Bea in their products. All you need a bean shell interpreter and you can supply a block of Java code at run time without changing & compiling your existing Java code and your Java code in bsh script will be executed at run time. And how would it fit into Generic Fixture model? Well we can simply pass full blown Java code with loops and branches in a String to bsh’s eval method and bsh will just execute whole Java code and return us the results. All we need is a freely downloadable jar file from Bean Shell website called bsh.jar so just go ahead and download bsh-*.jar from this Bean Shell download page.

So how do you get an instance of bsh interpreter? You can simply call a static method inside Generic Fixture called bsh() using GenericFixture.bsh notation (see example below). And be assured that Generic Fixture will give you same bsh interpreter instance (singleton) every time you call GenericFixture.bsh. But of course if you want an instance of bsh in a dynamic variable just use static method getBeanShell() of GenerixFixture. For ex: bsh=GenericFixture.getBeanShell will give you instance of bsh interpreter in a dynamic variable bsh=

A note about your dynamically created variables: All the variables that you’ve created in your test story will be available in bsh as well. Generic Fixture will create and populate these variables inside bsh interpreter for your convenience. And remember that while writing your Java code which will be interpreted by bsh you must not use varName= notation of Generic Fixture, just use it like any other Java variable like varName (without = at the end).

Enough talking, now let’s look at some working examples:

!path genericfixture.jar
!path bsh.jar
!| Generic Fixture | java.lang.Math |
| n=sqrt | 9 | | 3.0 |
| GenericFixture.bsh | n >= 3 | | true |
| GenericFixture.bsh | 4 <= n | | false |

Here in this example after Math.sqrt call value of dyamic variable n= is 3.0. Next 2 lines are executing Java code inside bsh. First condition n >= 3 is evaluated to true by bsh and second 4 <= n is compared to expected value false. Note that same variable n= became automatically available to bsh as n.

Now lets take a look at a looping example using bean shell.

!path genericfixture.jar
!path bsh.jar
!| Generic Fixture  | list=java.util.ArrayList |
| GenericFixture.bsh | for(int i=0;i<10;i++) list.add(new Integer(i+1)); |
| toString | |

In this example we have created an instance of ArrayList in a variable list=. Then we are passing a simple Java code with loop that stores first 10 numbers in this ArrayList to bsh. And finally we are just printing this list using toString() method of ArrayList.

Looks simple, isn’t it? So far I have covered some very basic examples. But I chose them to give you an idea of how to execute your custom Java code at run time and how to evaluate conditions and loops. In my next Blog post (hopefully shouldn’t take long time) I will cover a more useful example of testing a Restful web service using these advanced features.

Testing a JMS server using Generic Fixture

Its been a while since I posted my last blog on Generic Fixture. In my previous posts I demonstrated how to make use of Generic Fixture to write automated web tests, database tests, testing EJBs etc. Let’s see how to use Generic Fixture for testing a JMS (Java Messaging Service) server. What we are going to write essentially is translation of Java based JMS client into FitNesse using Generic Fixture, which can be used to write acceptance tests to validate almost any type of Java application.

For our demonstration I will be using Apache’s ActiveMQ, the most popular cross platform JMS provider. It’s open source product so please go ahead and download it from ActiveMQ download page. Once downloaded just unzip the installer zip file and start running activemq process from inside activemq-install-dir/bin directory.

Database testing using Generic Fixture

As I have mentioned in my Introduction to Generic Fixture post that we can use Generic Fixture to write acceptance tests to validate almost any type of Java application. In my previous posts I demonstrated how to make use of Generic Fixture to write automated web tests and testing EJBs. Let’s now see how to use Generic Fixture for writing queries against an Oracle database.

We shall keep the database connection parameters in a separate SetUp page as well as the connection closing code in a separate TearDown page. After that we shall write our query in main test page. That way we can utilize SetUp and TearDown pages in all of our test pages without repeating that code again and again in for each test.

I am assuming that your FitNesse server process is running on localhost on post 8000. If that is not the case then please change the URLs accordingly.

To test a database we shall need the database vendor supplied JDBC driver to be able to make JDBC calls. In this example since we are using Oracle we are going to need Oracle’s JDBC driver jar file. You can place your JDBC driver jar file anywhere on your system where FitNesse server is running and give the path in !path directive of FitNesse.

Use of variables, arrays and complex types in Generic Fixture

Please visit Introducing FitNesse’s Generic Fixture for introductory details about Generic Fixture.Here we shall see how we can use variables in Generic Fixture.You can use a variable myVar in test tables like this to store return value of method1:
| myVar=method1 | arg1 | arg2 | | returnValue |
….
….
or You can use a variable “params” in a test table like this to store the SUT (System Under Test, which is a HashMap here) itself:
!| Generic Fixture | params=java.util.HashMap |
| put | curr_id | 128 |
| size | | 1 |
| toString | |

and later to use this variable myVar in an argument list use this syntax:
| method2 | myVar= | arg2 | | returnValue |
….
or to use this variable myVar in return value use this syntax:
| method3 | arg1 | | myVar= |
….
or You can even use this variable myVar to instantiate a new class, use this syntax:
!| Generic Fixture | myClass | myVar= |
….

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.

Testing EJBs using Generic Fixture

As I have mentioned in my Introduction to Generic Fixture post that we can use Generic Fixture to write acceptance tests to validate almost any type of Java application. In my previous post I demonstrated how to make use of Generic Fixture to write automated web tests. Let’s now see how to use Generic Fixture for testing an EJB (Enterprise Java Bean).

Here is a sample Java code of a typical EJB client. Any Java developer who has ever written code to call EJBs will be well aware of following Java code snippet.

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.

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.

Download and Install Instructions

Install Requirements

You must have FitNesse framework installed on your computer and FitNesse server must be running on the computer where Generic Fixture is being installed.

To download Generic Fixture

Download the jar file genericfixture.jar containing full source code and compiled classes from Generic Fixture Sourceforge Site. Included classes have been generated using Sun’s JDK 1.5 Java compiler. Should you need to build Generic Fixture with any other JVM then make sure to put fitnesse.jar and fitlibrary.jar (provided in all the Fitnesse releases) in your CLASSPATH.