Tuning JMeter test plans with Sinatra

A while ago I had to create a JMeter test plan that would generate an almost constant load on servers without having a peak at the start of an interval and close to nothing for the rest of the period. To avoid unnecessary costs and have a reliable way to work on shaping the test plan it wasn’t an option to use remote servers. I had to find a way to mock the behaviour of those servers on my workstation fast and easy. Continue reading

Generics are weird, or I am weird

Yesterday, late afternoon, I stumbled across a compilation problem for one of my unit tests in Java. More specifically, compilation in Eclipse seemed to work fine but using Maven2 and the java compiler included in version 1.6.0_14 it complained about not being able to find the proper method.

Given the two classes below (modified for brevity, of course):

import java.util.*;

public class Foo<t> {
   private List> children = new ArrayList  ();

   public List> getChildren() { return children; }

   public Foo addChild(Foo child) { children.add(child); }
}
import static org.hamcrest.Matchers.*;
import static org.junit.Assert.*;

import org.junit.*;

public class FooTest {
   Foo parent, child;

   @Before
   public void setUp (){
      parent = new Foo ();
      child = new Foo ();
      parent.addChild(child);
   }

   @Test
   public void childAdded(){
      assertThat(parent.getChildren(), hasItem(child));
   }
}

For some reason it seems that omitting the type for Foo at line 7 makes Java drop the type of the getChildren method. The compiler will infer the return type of that method as a List (no generics). The type of the hasItem method from the hamcrest matchers, in line 18, is typed as Matcher. The result, during compilation the compiler will complain about line 18 in the test class. My current settings in Eclipse show this unchecked invocation as a warning. Nevertheless it compiles and runs. The standard Java compiler is very strict in this matter.

The quick solution is simple, just add a type to line 7 or do a cast at line 18. Doing both is overkill, but works too. Adding the type at line 7 is the best choice, because that way there is no need to explicitly cast every call to getChildren where this problem occurs.

import static org.hamcrest.Matchers.*;
import static org.junit.Assert.*;
import java.util.*;
import org.junit.*;

public class FooTest {
   Foo <Object> parent, child;

   @Before
   public void setUp (){
      parent = new Foo ();
      child = new Foo ();
      parent.addChild(child);
   }

   @Test
   public void childAdded(){
      assertThat((List<Object>) parent.getChildren(), hasItem(child));
   }
}

There might be a way to avoid this inconvenience by some simple changes to the Foo source code, changes I haven’t discovered yet. If there are any then I will find it!

Benefits of running your own test database

Setting up your own work environment proper and suiting your needs is an important and often undervalued part of software development. One of the things is to consider where and how to test the code. In big teams you have to conform to the standards or come up with a common understanding. I happen to have more freedom in this aspect, which made me change from using the “everything works on my pc” idea to the “keep everything centralized” one and then to the current one, a mix of both.

It has been only recently that I got it the way I wanted, more about that in another post. In the current configuration there is a production database, central test database that conforms with the latest changes in the version control system and a local test instance which has any changes which have not been committed yet. The main driver being that among others the continuous integration (CI) uses the central test database for testing and I want to continue development without breaking tests run by the CI server.

The advantages of my new configuration are:

  • the CI server can run its test without interference by developers
  • developers can their test without outside interference
  • speed, database access is less of a bottleneck

The disadvantages are:

  1. developers need their own test database to prevent interference
    1. the developer must update his test database schema with the latest changes from the central test database schema
    2. the developer must update the central test database’s schema, if necessary
  2. unrealistic performance expectations

Disadvantage 1 isn’t that hard to fix. For disadvantages 2.1 and 2.2 the solution is to restrict the number of developers on code that interacts with the database through a persistence subproject. And the last disadvantage might exist on several levels. The test database’s server might have different performance from the production server, which will certain differ between clients.

In conclusion I think I made my world a little better through these improvements. Another night with happy dreams ahead of me.