Gatling Java DSL

My favorite stress tool has been Gatling for many years now.

Scenarios are

• Easy to construct, It’s just code
• Easy to version. It’s just code
• Easy to run. It’s a simple command line that you launch in remote if needed
• Having great result graphs
• Easy to datamine. There is a simulation.log file that let’s you do some more digging when needed

My only complaints are

• You can’t change the running scenario
• It’s in Scala

The first one might be addressed by Gatling Frontline. I haven’t tried.

The second one is a bit more complicated to solve :-)

In fact, I don’t care that’s in Scala. But I would love to be able to core my scenario in Java.

So just for fun, I did a thought experiment. I’ve coded the Gatling API in Java and then coded the BasicScenario example using this API.

It’s not working for real

The API is just an emply shell. To know how different it would be from the Scala DSL.

The answer is: Not much.

My expectations were that I would need to rely on plenty of Java 8 features to get something close to the Scala DSl. But in fact, not even.

The main differences are:

• Variables are typed
• I’ve added a build method. But it’s just for style. I can get rid of it
• A bunch of semi-colons
• No syntactic sugar to create a map
• I’m using Duration is used to time units
• I need a run method where the setUp method is

That’s quite joyful and probably can be improved.

I’m now wondering if I could have used the Scala classes directly. I’m not good at making Java and Scala interacting.

So if someone is and want to try, please do so.

Manage emails in git

If you are like me, you tend to work on open source using your personal email and at YP using your enterprise email. But git doesn’t handle that well so you need to never forget to do

git config user.email henri.tremblay@somewhere.com

after each git init or git clone.

I finally had the time for work on an almost satisfying solution.

EasyMock 3.4 is out!

This version has finally removed the old (and ugly) partial mocking methods. You are now required to use the partialMockBuilder.

In exchange, you get really nice short methods to create your mocks: mock, niceMock and strictMock.

You also get a better stability since cglib and ASM are now embedded to remove a possible version mismatch with your own dependencies. Note that Objenesis will stay as an explicit dependency.

Change log

• #163 Incomplete sentence in documentation bug website
• #160 EasyMock should not depend on ASM but inline the code enhancement major
• #159 Remove partial mocking deprecated methods enhancement fixed major
• #158 Shorter mock methods core enhancement fixed major
• #155 Disable jar indexing enhancement fixed minor
• #11 User guide refers to methods not in latest release website

Out of SourceForge, all in Bintray

API_KEY=xxx
PASSPHRASE=xxx

# This is because I want the file upside down to create the older versions first
tail -r $1 > tmp.tsv

while read p; do
  version=$(echo "$p" | cut -d' ' -f1)
  date=$(echo "$p" | cut -d' ' -f2) 
  
  version=${version// /-}

  echo $version $date
  
  content="{ \"name\": \"$version\", \"desc\": \"$version\", \"released\": \"${date}T00:00:00.000Z\", \"github_use_tag_release_notes\": false, \"vcs_tag\": \"$version\" }"
  echo "$content"
  
  curl -v -XPOST -H "Content-Type: application/json" -H "X-GPG-PASSPHRASE: ${PASSPHRASE}" -uhenri-tremblay:${API_KEY} \
 -d "$content" \
    https://api.bintray.com/packages/easymock/distributions/easymock/versions

done <tmp.tsv

Migrating EasyMock Jira to GitHub

Following my previous article, I will now describe the Jira migration of EasyMock to GitHub issue tracker.

EasyMock Jira was on Codehaus. So I had to migrate it somewhere else. Instead of migrating to another Jira instance I’ve decided that EasyMock doesn’t need all that complexity anymore and that going to Github would enough.

The migration was made in two steps:

1. Save everything on my disk
2. Import everything in GitHub

Virtual goods are still mine: Open letter to The Economist

Finish migrating Objenesis to GitHub

With Codehaus and Google Code closing, I’m happily required to migrate Objenesis and EasyMock.

Both projects have an hybrid hosting using different platforms. I’ve decided to start with Objenesis which is easier to migrate. I’ll describe the process in this post. Hopefully, it will be helpful to someone but, in fact, I’m also looking forward to your feedback to see if I can improve my final setup.

So, Objenesis source code was originally on Google Code. I’ve moved it to GitHub some years ago mainly because pull requests are awesome. The website is also a GitHub page. Part of the documentation is on Google Code wiki, the binaries are on Google Code as well as the issue tracker.

Google being nice folks, they used to provide a nice way (https://code.google.com/export-to-github, now down) to migrate everything to GitHub. But I couldn’t use that because

• I don’t want the project to end up in henri-tremblay/objenesis. I want it where it is now, in the EasyMock organisation
• I only want to migrate the wiki and the issues since the sources are already there

So here’s what I did instead.

Issue tracker

The issue tracker was migrated using the IssueExporterTool. It worked perfectly (but is a bit slow as advertised).

Wiki pages

At first, I tried to export the entire Objenesis project to Github to be able to retrieve the wiki pages and then move them to the real source code. The result was quite bad because the tables are not rendered correctly. So I ended up manually migrating each page to markdown. There was only 3 pages so it wasn’t too bad.

Binaries

This was more complicated. Maven binaries are already deployed through the Sonatype Nexus. But I needed to migrate the standalone bundles. I’ve looked into three options:

• GitHub releases
• Bintray
• Both (GitHub releases exported to Bintray)

GitHub releases are created automatically when you tag in git. But you also seem to be able to add some release notes and binaries over that. I didn’t want to dig too much into it. I knew I wanted to be in Bintray in the end. And I wanted easy automation. Bintray was easy to use so I went for Bintray only. Be aware, the way I did the migration is low-tech (but works).

1. Make a list of all the binaries to migrate
   • Get them with wget https://objenesis.googlecode.com/files/objenesis-xxx.zip
2. Create an organisation, a distribution repository and an [objenesis package])(https://bintray.com/easymock/distributions/objenesis) in Bintray
3. Add my GPG key to my Bintray account
4. Upload everything using REST (curl -T objenesis-xxx.zip -H "X-GPG-PASSPHRASE: ${PASSPHRASE}" -uhenri-tremblay:${API_KEY} https://api.bintray.com/content/easymock/distributions/objenesis/xxx/objenesis-xxx-bin.zip?publish=1)

It works, the only drawback is that no release notes are provided. They’ve always been on the website

Project moved

Finally, I’ve set the “Project Moved” flag to target GitHub. This quite aggressively redirects you to GitHub if you try to access https://code.google.com/p/objenesis.

What I learned today

Microbenchmarking is fun

The history of partial mocking

Someone asked me this week to give some legitimate reasons to use partial mocking. It’s indeed a good question. Especially because the EasyMock documentation is explicit on telling that using it is probably a code smell.

The funny thing about partial mocking is that I’ve invented it to workaround issues we had at that time (2004… a long long time ago in the computer engineering world). It’s only later that we’ve discovered some legitimate usages. You see, when I first started to work on class mocking, it wasn’t possible to bypass the constructor yet (or at least, I wasn’t yet digging in the JVM far enough to be able to do so). So, I was using a lot of deductions to find which constructor will be the best to use. The algorithm was something like this:

1. Try to use the default constructor
2. If it’s not there, use the constructor with the less parameters and create a mock for each of these parameters
3. Pray it won’t fail when creating the new instance

Frequently, this method would fail because some nasty individual had put really agressive code in a constructor. For instance, I’ve seen constructors opening sockets…

So, to workaround that, I made it possible to select the constructor to use and also to pass real arguments to it. The arguments were not used afterwards. They were just there to prevent the constructor from crashing.

But then, something worse happened. Some constructors were calling other methods… And since no expectations were set (of course! The mock doesn’t exist yet!), mock creation was failing.

Partial mocking was born to solve that.

I made it possible to prevent some methods to be mocked so when the constructor would call them, they would behave as usual and I’ll get my mock. TADA!

Yes, it was ugly, hacky and I wasn’t really proud of it but that was the best I could do at that time (remember: 2004).

Not so much later, I found a way to bypass the constructor entirely the same way HotSpot was doing it during serialization. The main drawback was that EasyMock was now working only on HotSpot since the code was HotSpot specific.

The good news are that this code was already used by a bunch of other frameworks like XStream for instance. So other JVMs were starting to be compliant. I remember asking the JRockit team about it and two minor versions later, it was there.

Still, that’s was caused the creation of Objenesis. The magical library that creates objects without calling the constructor on any JVM. In fact, Objenesis is not that useful anymore because we have Unsafe.allocateInstance. Unsafe also is OpenJDK specific but so many frameworks are using it that pretty much everyone has implemented it. However, I’m still using Objenesis for two reasons:

• You never know when a JVM won’t be compatible with Unsafe
• My benchmarks have shown the using JVM specific code is way faster than using Unsafe

So I’m staying on Objenesis for now (and there is an instantiator using Unsafe so there’s no drawback using it).

Anyway, back to partial mocking.

So, we are now able to bypass the constructor and partial mocking was created because we were not able to. Why is it still there?

There are two main usages. The first and most legitimate one is to test the Template Method Pattern. Let’s say you have an abstract base class with abstract methods and concrete methods.

public abstract class BaseClass {
  public boolean beTruthy() {
    // stuff
    boolean b = doSayTheTruth();      
    // other stuff
    return b;
  }   
 
  protected abstract boolean doSayTheTruth();
}

You want to test the concrete ones.

• You could create a fake implementation, but that’s annoying.
• You could just use a real implementation but then it will make you test more than needed.
• Or you could create a partial mock.

In fact, when creating a partial mock, EasyMock now automatically considers that abstract methods will be mocked and concrete methods won’t.

So you could do

BaseClass myClass = createMockBuilder(BaseClass.class).createMock();
expect(myClass.doSayTheTruth()).andReturn(true);
replay(myClass);
assertTrue(myClass.beTruthy());
verify(myClass);

How sweet.

The other reason is a little bit less legitimate. Let’s say you have a class with a bunch of methods calling each others.

You would like to test the class but testing everything at once is nearly impossible.

A good solution is to test the methods one after the other by using partial mocking.

1. You will test the first method by mocking everything it calls.
2. You will then test another method down the stack by mocking everything it calls.
3. And so on and so on.

Of course, that’s bad code! But if there are no tests, you can’t refactor! Step one, the tests. Step two, refactor. And yes, during the refactoring, the need for partial mocking should disappear. But that doesn’t mean partial mocking isn’t helpful.

That’s all for today. Happy partial mocking. I hope you find this story interesting and/or useful.