EJB Testing

LegacyForum

How does Jtest deal with EJBs?

==========================================
J2EE - The How's and What's
==========================================

The most popular question Jtest end-users ask is "Can I test my Ejbs?".

The answer is, yes.

The second most popular question end-users ask is, "How?"

"Enterprise web applications, which live on networks and are accessible through browsers, are redefining Web Software. This is the next wave of computing" - www.jboss.org/business/jboss-overview.html

Jtest end-users doing J2EE development develop Enterprise Java Beans which run inside of an application server. The application server sits on a network and is accessible through client software, usually a Java applet or other lightweight Java program.

EJBs may perform various types of computing tasks and are used in many industries. EJBs make it possible to "serve" application computing power to clients across a network. All computing is done inside of the App Server and removes the work on the client side. Servers are usually very fast machines with lots and lots of memory and disk space.

Jtest end-users ask, "How do I test EJBs?", "How does Jtest work with my AppServer?" and "Can I test my beans after they have been deployed onto the server?" Read on...

How to test EJBs with Jtest?

This README covers White-Box and Black-Box testing functionality of Jtest as these are the features requiring explanation with regards to Enterprise Java.

The first thing to make clear is Jtest's definition of the word Stubs.

Jtest Stubs are replacements for method invocations. Jtest gives the option of replacing calls to the actual method by calls to a stub method that says what the return value should be. Jtest provides automatic stubs and also allows users to define their own. Jtest provides automatic Stubs for calls to operations that take place over the network, or file system, for example, I/O, Network, J2EE, RMI, Database Connectivity, and CORBA.

Throughout the rest of the discussion please understand that when "external reference" is used it is meant to describe things that happen on the file system or over the network.

Please do not confuse Stubs used in the Jtest context with those used in an Enterprise Java context. They are different.

If, during testing, Jtest encounters a class making references external to it's "Tested Set" (the classes in the enclosing package of the tested class) Jtest will automatically generate a "Stub" for the reference if the reference is an external resource (I/O, etc.).

The Jtest Stub should not be confused with Enterprise Java Stubs. They are completely different entities.

Please allow a moment for digression. Jtest can automatically test Java classes with white-box automatic testing. The way it does this is by analyzing the class file, then executing the class file in an isolated manner. The class does not know it is being executed by Jtest. It does not know it is not running in an application. Jtest has provided a simulated container for the class and is executing the class isolated from any external references.

If it makes a reference to a method that invokes an external resource (such as I/O, J2EE, Network, etc), then a Stub is used. It is used so that Jtest can achieve high coverage of the tested class and/or find exceptions in the tested class.

Also, with Jtest's Stubs it is possible to test an EJB or any class without the entire framework the class depends upon (database, AppServer, etc.)

Please bear in mind, the discussion on Jtest Stubs is meant to be general and is entirely unrelated to the nature of the tested class, whether it be an EJB, RMI, or a plain-and-simple Java class, Jtest treats it the same. If during White-box testing, an external reference is made by the tested class, Jtest generates a Stub for that reference and provides the data or method call itself (rather than calling the actual external reference).

Some clarification is needed (and is now provided) on how all of this relates to Jtest White-Box testing and Enterprise Java.

End-users often have questions such as:

"What version of My AppServer does Jtest work with?"

"What version of EJBs does Jtest support?"

Because Jtest automatically generates Stubs when an external reference is made, version information and EJB setup is not relevant.

Please do not confuse a Jtest Stub with an Enterprise Java stub, they are different.

When Jtest does White-Box testing on an EJB, it provides a "simulated container" for the bean in the form of automatic stubs for the calls to the container. The bean does not know that it is not running inside of a "true" container.

The bean does not know that it is being stimulated with automatically generated data. The AppServer is not involved with White-Box testing as Jtest is "containing" the EJB to test it. Any external reference that is made by the bean, be it to the server, another bean, or a
database, is handled by an automatically generated replacement method called a Jtest Stub.

Users often ask:

"Before a call to an EJB method is executed certain steps need tohappen ..."

"What types of testing does Jtest does it do on EJBs?"

All setup required by a bean is provided by Jtest and is not related to any specific server. If the bean makes server specific method calls, they are stubbed by Jtest. It simulates the "container" by intercepting all external references provides automatically generated
method/object replacements (or Stubs), in their place.

The type of testing Jtest does on EJBs is the same as it does for any class that it tests. It generates input information to 1) achieve very high coverage and 2) find any uncaught runtime exceptions.

Many users have been confused because they are considering classes Enterprise Java as special. To Jtest, they are not. To Jtest they are the same as any plain-ol' Java class.

The main (key) point follows:

While Jtest is testing a class, if the class makes a reference that is external to it's enclosing package, or to an external resource, then Jtest intercepts that call and replaces it with an automatically generated stub. It does so, because it is a unit testing tool and
tries to get high coverage and find as many exceptions as it can -- all automatically.

White-box testing EJBs is very effective for testing the business logic of the bean.

Sometimes, users ask:

"What info do we use to create the stub and skeleton info?"

"Can we use the stub and skeleton from our AppServer?"

How Black-Box testing functionality of Jtest can help the testing of Enterprise Java apps also deserves coverage by this discussion.

Advanced users often get involved with the construction of complex test cases. These test cases are usually test clients that interface the beans. They would like to have some kind of automated way to manage and organize testing -- Jtest provides this.

When the EJB developer is finished developing the bean, he or she deploys the bean to the server so that it may be tested. Often the developer writes a small test client, perhaps using the JUnit or J2EEUnit testing framework.

With black-box testing, Jtest actually makes all the real calls. When it runs a testclass (Jtest TestClass, JUnit, etc.). Jtest simply runs the client code. All external resources are referenced, etc, exactly as if the client were being run outside of Jtest and by the Sun's Java virtual machine.

It the black-box test, Jtest makes all the calls and does not intercept any calls and does not provide any stubs. So, if a client talks to a bean which talks to other beans or the server or a
database, the exact same thing will happen when the client is run by Jtest as when it is run by the Java virtual machine.

Now, again, one might be curious, about version information. Actually it does matter with Black-box testing but as it turns out, is not that complicated.

Any AppServer, or J2EE API, or any API or ThirdParty Tool for that matter, that is supported by the Sun JDK 1.3 virtual machine, will be supported by Jtest as it implements a 1.3 virtual machine.

Users ask:

"How can I use "assert" to create a TestCase and Test my EJB method?"

Well, the answer is simple. You write a Jtest TestClass and use asserts to make sure the client and bean are interacting as expected. You use asserts with the test client to check that the values you get from the bean are expected. Whenever an assert fails Jtest reports an
error.

If the client runs with Sun's VM, then it should run with Jtest as well. In other words, any client that runs under the Sun 1.3 VM will run with Jtest.

Now, some people may ask:

"What extra benefit do I get if I use Jtest to do my the testing of my EJBs?"

White-box testing has proven to be very effective in testing the business logic of the bean, the construction of the bean, and finds under what circumstances the bean will throw runtime exceptions.

By generating input data for methods and Stubs for external resources, the bean's construction is thoroughly tested. Input generated by Jtest is very hard for a human to generate.

Functionality testing of the beans can be done and handled by Jtest after the black-box tests are written. Other popular test frameworks may also be included by Jtest (JUnit, HTTPUnit, and J2EEUnit).

Design by Contract -- this topic is reserved for another paper, entirely. Please see the manual with regards to DbC, but in a nutshell, DbC by Jtest makes it possible to put the method
functionality specification directly in the code (by using Javadoc comments).

Static Analysis -- enforce a wide set of coding standards and create your own.

Regression Testing -- who could forget regression testing? If anything changed since the last time Jtest tested the class, it notifies you right away.

Hopefully this has clarified the issues of Enterprise Java and how Jtest works with them.

In summary, they are not treated specially by Jtest, they are simply Java classes and Jtest executes them to test if it can break the code.