| Sign In/My Account | View Cart |
Taking JUnit Out of the Box
Pages: 1, 2, 3, 4, 5
TestSuite and
add a test to it to be run remotely. This is achieved by specifying
the JUnit class (with an optional test method), as well as the name
of the agent that should run this specific test.
Here is an example of how this is done:
// create a regular TestSuite
TestSuite suite =
new TestSuite("Test for org.pisces.testers");
// create a wrapper for a regular case
RemoteTestCase rtc =
RemoteTestCase.wrap(RemoteTestTestCase.class
,"someTestMethod", "remote1");
// add test case to TestSuite
suite.addTest(rtc);
The next section of this article will provide an example of a
distributed test scenario and the code of its
TestSuite.
Let's say we have a web application. A user logs in, gets a service, and then logs out. We want to make sure that our security module prevents a single user from concurrently logging in on two different computers.
We have created a MyTestCase test case object, as
shown before, that has two test methods. The first,
testLogin(), makes sure we can log in for the first
time, and a second one, testLoginFails(), makes sure
that the second login fails.
Here is what a test suite that utilizes Pisces might look like:
public class RemoteTestSuiteExample extends TestSuite {
public static Test suite() {
// configure and start the com layer
JMSRemoteTestCommunicationLayer com = null;
try {
com =
new JMSRemoteTestCommunicationLayer
(RemoteTestRunner.name,
new MantaConnectionFactory());
} catch (JMSException e) {
throw new RuntimeException(e);
}
RemoteTestRunner.setCom(com);
// do the JUnit thing
TestSuite suite =
new TestSuite("Test for org.pisces.testers");
// run method testLogin in class MyTestCase
// on remote agent remote1
RemoteTestCase rtc =
RemoteTestCase.wrap(MyTestCase.class,
"testLogin", "remote1");
suite.addTest(rtc);
// run method testLoginFails in class MyTestCase
// on remote agent remote2
RemoteTestCase rtc1 =
RemoteTestCase.wrap(MyTestCase.class,
"testLoginFails", "remote2");
suite.addTest(rtc1);
return suite;
}
}
If all goes well, the remote agent (called remote1)
tries to log in and succeeds. When the other agent (called
remote2) tries to log in with the same user and password,
it fails because the user is already logged in on a different
computer.
This test could have been more complex; for example, by adding a
testLogOut() method and performing other security
checks, but as an example I wanted to keep it simple.
In this example, I have utilized a serverless JMS provider called MantaRay, an open source messaging middleware package that is based on peer-to-peer technology. In the latest release of Pisces, you can find several examples that utilize a JMS communication layer and other examples that use a multicast communication layer.
Bugs are not fun, but with the help of JUnit, a widely used open source framework for automated testing, the task of running multiple test cases becomes much easier. Many projects extend the functionality of JUnit, but up until now, tests always had to be limited to one machine. With the help of Pisces and some "out of the box" thinking, we can now finally create complex and distributed test scenarios.
Amir Shevat is a senior software developer with eight years of experience in computing.
Return to ONJava.com.
Showing messages 1 through 3 of 3.
A unit test is a specific kind of test: A single piece is taken out of it's operational environment, placed in a test harness, and tested. For example, you might take a gear out of an engine and test it to make sure it can endure operation inside of the engine over time.
I think you've confounded unit testing with integration or functional testing, and of course JUnit isn't going to provide a lot of out-of-the-box help with this.
For example, you state:
JUnit's weaknesses are also well known. It supports only synchronous testing and offers no support for call backs and other asynchronous utilities.
A call/callback mechinism is two units (two methods). You also state:
JUnit is a black-box testing framework, so testing problems that do not directly affect functionality (such as memory leaks) is very hard.
JUnit is white-box (or clear box) testing. You write code. You write tests for the code you wrote. There is nothing about the code being tested that is hidden.
Yes, finding memory-leaks with JUnit will be difficult, since your tests don't run in thier native environment (the application), but in the test harness.
Additionally, it does not provide an easy-to-use scripting language, so you must know Java to use JUnit.
I agree that a scripting language is nice when writing unit tests, however, if you're writing code in Java, how is it difficult to write unit tests in Java?
Toto, I don't think we're in Kansas anymore
Moreover if I use some test coverage tool like Cobertura. Will it also cover the results from Class B along with Class A.
Thanking you in advance