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.

import javax.naming.InitialContext;
import javax.naming.Context ;
import com.sales.Product.*;

public void TestPrice() {
   try
   {
      // create and load properties
      Properties props = new Properties();
      props.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
      props.put(Context.PROVIDER_URL, "t3://localhost:7001");

      // get initial context using loaded properties
      InitialContext context = new InitialContext(props);

       // JNDI lookup
      Object jndi = context.lookup("ProductHome");

       // narrow down remote object to get remote home
      ProductHome home = (ProductHome) javax.rmi.PortableRemoteObject.narrow(jndi,
                                   ProductHome.class);

      // create service from remote home
      ProductService productService = home.create();

      // check if Product IDs exist in Database
      boolean result1 = productService.isValid(1801);
      boolean result1 = productService.isValid(9999);

      // assert our results
      assertEquals( result1, true );
      assertEquals( result2, false );
   }
   catch (Exception ex)
   {
       ex.printStactTrace();
   }
}

This code is first trying to do a lookup for JNDI object “ProductHome” (remote home) deployed on a Weblogic application server. Upon a successful lookup it creates a service object from remote home and finally calls isValid(int) method on the service class.

Now let’s see how are we going to implement this code in a FitNesse test table using Generic Fixture.

!path weblogic.jar
!path productEjbs.jar

'''Set debug ON for Generic Fixture'''
!| Generic Fixture | Generic Fixture |
| set debug | true |

'''Load the required properties'''
!| Generic Fixture | props=java.util.Properties |
| put | javax.naming.Context.INITIAL_CONTEXT_FACTORY | weblogic.jndi.WLInitialContextFactory |
| put | javax.naming.Context.PROVIDER_URL | t3://localhost:7001 |
| toString | |

'''Load the Remote Home class'''
!| Generic Fixture | java.lang.Class |
| homeClass=forName | com.sales.Product.ProductHome |

'''Lookup JNDI from Initial Context'''
!| Generic Fixture | javax.naming.InitialContext | props= |
| jndi=lookup | ProductHome |
| obj=javax.rmi.PortableRemoteObject.narrow | jndi= | homeClass= |

'''Cast Narrowed object to Remote Home object'''
!| Generic Fixture | homeClass= |
| homeObj=cast | obj= |

'''Create service object from remote home object'''
!| Generic Fixture | homeObj= |
| service=create |

'''Check if given Product IDs exist in Database'''
!| Generic Fixture | service= |
| isValid | 1801 | | true |
| isValid | 7000 | | false |

Since we had to operate on multiple objects and classes, we have heavily used the variables feature of Generic Fixture. Most of the test code is self explanatory with the comments provided on top of each table. Only tricky thing is to call Class.Cast(Object) method to get the casting right for ProductHome home = (ProductHome) javax.rmi.PortableRemoteObject.narrow(jndi, ProductHome.class) call in Java code.

Go ahead and give it a try.

So using Generic Fixture we completely eliminated the need to write Java code given in above section to test our ProductHome EJB. Writing EJB test in Generic Fixture of course has huge advantage over writing Java code. These test tables can be altered by any non-developer. For ex: if there is a new requirement to test validity of Product ID: 5319 then it is as simple as adding this line in the last table:

| isValid | 5319 | | true |

Which is much easier than finding a developer to change and re-compile the Java code.

I intentionally chose a simple operation on ProductHome EJB here to pass on the idea but almost any operation on EJBs can be performed using this approach, thus giving us the ability to build really robust and useful acceptance tests without writing any Java code.

Advertisements

8 thoughts on “Testing EJBs using Generic Fixture

  1. Eloise says:

    Hi Anubhava,

    Thanks for your answer, it’s more clear.
    So I ll try to implement the Generic Fixture !

    Regards
    Eloise

  2. Hi Eloise,

    If you like to know how to do that EJB test in Java then please see TestPrice method in my post for equivalent Java calls. However if you’re asking how to write same test script in FitNesse without using GenericFixture then I don’t think that is possible. Other FitNesse fixtures don’t provide this feature of calling all kind of Java APIs the way GenericFixture does. That was the whole reason I came up with the idea of GenericFixture.

    Thanks.

  3. Eloise says:

    Dear Anubhava,

    I’m a very, very new Fitnesse user.

    Your post is very instructive. You tell us how to test our ejb with Generic Fixture, but I don’t how to do without !
    I didn’t find this information on the fitnesse web site, so I don’t understand how Fitnesse can interact with ejb linked to a database.

    Could you tell me where I can find these informations ?

    Eloise

  4. Dear Aristotelis,

    Thanks for your kind offer to work with the code of Generic Fixture. Complete source code of the “Generic Fixture” is included in the genericfixture.jar that you’ve been using. I have also included the build.xml file for convenience. It will need fitlibrary.jar and fitnesse.jar to build. Please let me know if there is any problem in accessing the source files or building them.

    Now coming back to the problem you are facing. Have you tried running Generic Fixture in debug mode. This can be enabled by this script:

    !| Generic Fixture | Generic Fixture |
    | set debug | true |

    Your test script:
    !| Generic Fixture | myobjdb=ourdomain.databuilder.fit.FixtureContext | array: b,c,d |

    Is trying to call constructor of the class FixtureContext by passing an array of 3 elements. Please verify this is what your intent is.

    If you face any hurdle in resolving your issue please write back.

    cheers,
    Anubhava

  5. Aristotelis says:

    Hello Anubhava,

    We have been trying to use a jar of ours with Generic Fixture but we get an error that we can not decipher.

    It seems that the error description presented derives from the exception handling and not from the actual error itself and hence it does not help us to debug the problem.

    Our developers here have offered to work with the code of Generic Fixture to help surface the original errors (contributing any work done back to you naturally), however I do not know where to get the code from. Is it available anywhere?

    Our code is:
    !path mydatabuilder.jar

    !| Generic Fixture | myobjdb=ourdomain.databuilder.fit.FixtureContext | array: b,c,d |

    and the error we receive is:

    java.lang.NullPointerException
    at GenericFixture.readRow(GenericFixture.java:291)
    at GenericFixture.doRows(GenericFixture.java:765)
    at fit.Fixture.doTable(Fixture.java:153)
    at fit.Fixture.interpretFollowingTables(Fixture.java:119)
    at fit.Fixture.interpretTables(Fixture.java:105)
    at fit.Fixture.doTables(Fixture.java:79)
    at fit.FitServer.process(FitServer.java:71)
    at fit.FitServer.run(FitServer.java:52)
    at fit.FitServer.main(FitServer.java:43)

    thanks in advance,
    Aristotelis.

  6. Ismail says:

    Hi anubhava :

    Thank you for your response,we will also try to put the path of our jar file that is located in the deployment directory of jboss.

    After a jboss deployement, the ear is splitted by jboss anf the jar files can be directly accessed

    We will let you know when we achieve this task.

    Thank You
    Ismail.

  7. Hi Ismail,

    Thanks for your comment. Yes EJB was packaged in an EAR file and deployed on a Weblogic 9.2.x server. (In this example it was running on localhost port 7001 but it can be anywhere)

    If you see my example I have this line on top the test:
    !path productEjbs.jar

    This line is basically adding product EJBs jar file to Fitnesse’s classpath. Is this what you were asking or I didn’t get your question correctly?

    cheers,
    Anubhava

  8. Ismail says:

    Hi anubhava :

    Nice post :), that will be very useful for us,we are looking to do some black box testing on a business application that is using services implemented as ejb3.0 services.

    What is our ejbs are packaged in an ear file?,how will we do to access the jar in the ear file that contains the implementation of the ejbs ?

    Thank You
    Ismail.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s