Installing The Grinder On Ubuntu 10.10

One of my development goals for this year is to learn a lot more about J2EE application performance. Gathering performance statistics for a J2EE application isn’t really difficult, but I soon realized that before I could do that, I needed to find a way to run my applications under load.

At work, we typically do this by using a non-free tool such as LoadRunner. This tool is very popular and it seems to work fairly well, but I can’t afford the license or training costs.

Luckily, I found an open source alternative called The Grinder. This tool’s workflow is similar to the one used by LoadRunner, and fit all of my requirements, including:

  • Free and open source (FOSS)
  • Cross Platform – It is written in Java and runs well for me on Linux and Windows
  • Mature – The software has been around for nearly 10 years and it is currently on version 3
  • Easily Scriptable – You can write load tests using Jython, which is a version of Python that is written in Java.
    • If you haven’t used it before, Python is a great scripting language that does a good job balancing functionality and ease-of-use.
    • Jython is also a very well-established and mature FOSS project. I was using early versions of it as far back as 2001.

The problem is that I had trouble finding many tutorials on using The Grinder. I therefore decided to write a couple of tutorials, covering the following topics:

  1. Installing The Grinder on Ubuntu 10.10
  2. Executing the Hello World test
  3. Recording and executing a test against a local web application

I’ll cover the first bullet point in this article, and I hope to have the other bullet points covered very soon in othe articles.

Installing The Grinder

The Grinder does not include an installation script or startup scripts for some strange reason. You therefore need to do all of this stuff yourself. Here’s how I did it.

Prerequsites

The only prerequisite for The Grinder is Java 1.5 or greater, but some features can only be used with Java 1.6. So let’s install it:

    $ sudo apt-get install sun-java6-jdk

Everything else that you need to run The Grinder is part of the package.

One more thing that you may want to install is the pychecker package. This tool will check your test scripts for any typos or indentation errors. Simply install it like this:

    $ sudo apt-get install pychecker

It’s not required, but it can save you some big headaches later when your script fails to run.

Installing The Package

Since the script doesn’t have a “native” installer and there isn’t an Ubuntu package, we’ll do things the hard way:

  1. Download the latest version of Grinder 3. I’m using version 3.4. This should be a zip file.
  2. Unzip this file in an arbitrary location. For me, this created a folder called grinder-3.4.
    • $ unzip grinder-3.4.zip
  3. Move this Grinder folder under the /opt folder.
    • $ sudo mv grinder-3.4 /opt
  4. To make our lives a little simpler, make yourself the owner of the /opt/grinder. My username is tom, so this is how I would do this:
    • $ sudo chown -R tom:tom /opt/grinder-3.4

Now The Grinder is officially “installed”, but it’s a little clunky to use. Let’s fix that.

Your CLASSPATH

Adding the grinder.jar file to your CLASSPATH variable will make it much easier to use The Grinder:

  1. Open your $HOME/.bash_profile file using a text editor.
  2. Look for a CLASSPATH variable.
  3. If one exists, then add /opt/grinder-3.4/lib/grinder.jar to it.
  4. If the CLASSPATH variable doesn’t exist in this file, then add the following to lines:
    • CLASSPATH=$CLASSPATH:/opt/grinder-3.4/lib/grinder.jar
    • export CLASSPATH

Now either log out and back in or source your .bash_profile file by typing the following command:

    # you should only have to do this the first time
    $ source ~/.bash_profile

Aliases

Once the grinder.jar file is in your classpath, you can start different Grinder components using their full Java path. For example, you should be able to start the Grinder Console using the following command:

    $ java net.grinder.Console

This isn’t terribly difficult, but it’s hard to remember and tedious to type. We’re therefore going to create alias shortcuts for the Console and TCPProxy commands.

Open your $HOME/.bashrc file in a text editor and add the following lines anywhere in the file:

    alias gconsole="java net.grinder.Console"
    alias gproxy="java net.grinder.TCPProxy"

Now either log out and back in or source your .bashrc file by typing the following command:

    # you should only have to do this the first time
    $ source ~/.bashrc

Finally, you can start the Grinder Console and TCPProxy components by simply typing gconsole and gproxy, respectively.

Conclusion

You should now have a working version of The Grinder that is very easy to execute. In my next tutorial, I’ll show you how to execute a hello world test so that you can start to “kick the tires” of The Grinder.

Pros & Cons of Offshore testing

This is to discuss pros & cons of off-shore testing.

Let’s say your organization is based in UK with its core business in UK. Software development is mostly done in UK but the decision has been made to outsource software testing to India. Here is my list of pros & cons based on my experience:
Pros:
  • Cost savings as the daily rate for a test resource in India is significantly lower than the UK equivalent
  • Willingness to work long hours and overtime in comparison to UK-based test resources (on average)
  • The culture of high ambition to succeed with the focus on education and learning

Cons:

  • Remote location, i.e. lack of face-to-face interactions with developers, business and other project stakeholders, which is a big issue especially if your project or organization uses an agile approach to software development such as XP, Scrum or DSDM
  • Time-zone difference of several hours. This may result in a long defect turn-around because of the different working hours of testers and developers (defect identified in India but debugged & fixed in UK and then returned to India for confirmation & regression test)
  • Detachment from business and development may result in misunderstandings and mistakes (both technical and political)
  • Language and cultural barriers may sometimes result in ‘being quiet’, i.e. not asking questions when not sure about something because not wanting to be seen as they do not understand something with a fear of ‘losing face’. It is known that giving feedback freely to managers is culturally not so common in India as it is in the UK.

I am sure there are other pros and cons that I have forgotten to mention. Therefore, it would be great if you could add yours and share your view on the off-shore testing based on your experience.

In addition to just listing pros and cons, I wonder how would you mitigate the cons and, if possible, transfer them into opportunities.

Junit in Eclipse

Unit testing is defined as “ Each module is tested alone in an attempt to discover any errors in its code ”. Its always a good practice to test each unit of your project independently as it saves time and effort while integrating the modules.

JUnit provides close relationship between testing and development. As developers write the code, they use the JUnit test runners to verify how much it deviates from the intended goal. Normally it is a standard practice that the code developers themselves write unit tests for their code.

First step is to put “ junit.jar ” on the build Path. Go to project properties and click “ Java Build Path ”. In the Libraries tab click “ Add External JARs ” and then browse to “ junit.jar ”.

Suppose we want to test method called “ getSmallest() ” in class “ Test.MainClass ”. This method takes an integer array as input argument and returns smallest integer from that array. We will write “ TestCase ” to test this using Junit.

package Test;

import java.util.*
public class MainClass {

public static void main(String[] args) {

 }

public static int getSmallest(int arr[]){

 	Arrays.sort(arr);

 	return arr[0];

 }

}

Right click “ project name ” and click “ New ” – > “ Junit Test Case ”. New JUnit Test Case window will open. Name the test case and select class for which you are writing the test case. In my case, I selected Test.MainClass. Click Next.

Now we have to select the methods from the chosen class for which test stubs will be generated. In my case, I selected “ getSmallst(int[]) ”. “ Click Finish ”. Test stubs for the method is generated but we have to write a little code to test it.

Review the code below:

package Test;

import junit.framework.TestCase;

public class test_case_getSmallest extends TestCase {

public test_case_getSmallest(String arg0) {

 	super(arg0);

 }

protected void setUp() throws Exception {

 	super.setUp();

 }

protected void tearDown() throws Exception {

 	super.tearDown();

 }

public void testGetSmallest() {

MainClass o = new MainClass();

 	int[] myarray ={100,200,30};

int val;

 	if((val = o.getSmallest(myarray)) != 30)

 	{

 		System.out.println("Shortest value returned is :
" + val);

 		fail("Not right result.");

 	}

}

}

To run it, right click the test case (test_case_getSmallest.java) and click “ Run As ” – > “ JUnit Test ”. Test will run and the results will be shown. In my example, I got the following results.

Now to see failures. We changed the “ testGetSmallest() ” code as

public void testGetSmallest() {

MainClass o = new MainClass();

 	int[] myarray ={100,200,30};

int val;

 	if((val = o.getSmallest(myarray)) != 100)

 	{

 		System.out.println("Shortest value returned is :
" + val);

 		fail("Not yet implemented");

 	}

}

Output I was shown is:

In this example,we are just testing a method using a simple test case. We can test more than one methods using same test case as well. For instance, we could have more than one methods in our class “ MainClass ” and then more than one test stubs in our test case “ test_case_getSmallest() ”.