converting 2K+ tests to junit 5 in one day

I set myself a goal to see if I could convert all the CodeRanch JForum tests to JUnit 5 in one day. And I mean with Java 5 package names, not just running them in JUnit 4 mode. (I wanted to see what edge cases I encountered). Let’s see how that went.

Forking

Ant doesn’t currently support JUnit 5. So I decided to create a fork of the code base for playing with JUnit 5. Which is fine. I wanted to automate as much of the process as possible so it’ll be easy to redo when the time comes. It’s also good because then I don’t have to worry about whether everyone’s IDE supports JUnit 5 yet. IntelliJ does if you are on the latest version and Eclipse does if you fiddle with it. Probably better to wait until after the official release of JUnit 5 and Eclipse before using JUnit 5 in the trunk anyway.

Scope reduction

I decided to only update the unit tests. We also have some functional tests with an odd hacked together way of loading the database.  (I wrote a lot of it so not criticizing others.) I’m sure this can be improved in JUnit 5. Will wait until release for that as well.

JUnit 3.8

We have 15 classes that still reference JUnit 3.8. They used a mix of a superclass that did inherit from JUnit’s test case and some that used JUnit 4 style annotations too. I decided to go through these by hand in the trunk (and my branch) and get rid of the references to JUnit 3.8. This was a pain because each one was a special snowflake. One even said it was deprecated with replacement code listed. But it took under an hour; a few minutes each. So not terrible.

As I was going, I missed noticing that the class missed annotation. I was excited to see that SonarLint flags this!

Migrating most of the code

I ran a program to migrate most of the code to the new syntax. Here’s the project on github.

This left me with 83 compiler errors to look at. Of those…

Manual clean up

  • Parameterized tests. The manual gives good examples of the options. Conversion was easy; I used a method source. I did run into two problems.
    • SonarLint false positive – If you only have parameterized tests, SonarLint still flags the class. This was fixed in Sonar per SONARJAVA-2390. However, SonarLint hasn’t been released since so need to ignore the error in my mind.
    • Eclipse false positive – If you only have parameterized tests, Eclipse doesn’t recognize it as being a JUnit test. I didn’t search to see if this was reported since it is so easy to work around. To “solve” both these problems, I added a non-parameteirzed test to the class.
  • Timeout. I had one test that used the @Test(timeout) parameter. It was clear from the manual how to convert this. I like that specifying the time uses Java 8’s Duration class. This lets you specify the timeout in a readable way rather than in milliseconds.
  • Expected exception. I had 16 tests that used the @Test(expected) parameter. I thought about automating this but decided against it. This is a good opportunity to add an assertion about the message to most of them. Which we should have done originally. But it was *so* easy to just write the type and be done with it before. Also, it isn’t 16 distinct classes. A number of them have multiple validation type methods.
  • About 25 of our tests use JMock. @RunWith(JMock.class) doesn’t go with JUnit 5. Since JMock was abandoned (last release in 2012), I decided to switch to the “long way” and call context.assertIsSatisfied(); for now. About half of them extend the same superclass at least. I also made a note that we should migrate away from JMock.

Then I attempted to run all the converted tests

I ran into one problem

  • One of our tests was relying on the order in which the @Before methods were run in the superclass. This behavior was never guaranteed and changed from JUnit 4 to JUnit 5. I fixed the code to not rely on the order. (And or course, the place this happened was a superclass test so it resulted in a large number of failures until I figured out what was going on!)

Observations

I met my challenge. 2K+ tests migrated in one day. And I observed that one superclass caused the vast majority of the special cases!

“why are you even here?”

I went to part of the Toastmasters conference last week. At one of the sessions, I was on my tablet and the lady next to me said “why are you even here if you aren’t going to pay attention”. I was doing a mix of:

I obviously didn’t get into this with the woman who said this. But I did email myself that the answer would be a good blog post. I use a computer/tablet during conferences in two scenarios.

Scenario 1: I want to be fully immersed in the material

As noted in the presentation she was hassling me in, humans have a short attention span. Live blogging prevents me from being distracted. I’m *very* focused on what is going on because I’m listening and processing to write. This only leaves me with a tiny bit of spare brain power. Which I use for scanning comments from others ex: twitter.  And it prevents me from having enough brain power to attempt doing something that has the potential to steal my focus like email.

Now granted, I wasn’t live blogging at the Toastmasters conference. But it is common for me to do so at tech conferences. For example, see my QCon blog posts. Hard to argue I wasn’t paying attention there!

Scenario 2: Only listening some

Sometimes you are only interested in part of a session or the speaker isn’t great. Not bad enough to get up and leave. But not enough to want to pay full attention. (If I’m at a session after work on the weekend or on a vacation day, it’s completely up to me how much attention I pay.) And there’s an advantage to this. Paying partial attention, you might learn something. Leaving you guarantee you’ll learn nothing.

This Toastmasters event was on my vacation time and I paid the entrance fee. There were plenty of the empty chairs in the room so I wasn’t taking a seat away from someone who would pay full attention. And I didn’t sit in the front so I wasn’t taking up a “good seat”. So completely up to me what I wanted to do in the room. At least I wasn’t bothering anyone. I sat next to another person at this event (not this lady) who took notes by repeating what the speaker said into their phone.

As far as why did I come – I wanted to see what the semifinals and world championships of public speaking were like. And I wanted to go on vacation to Vancouver. So I combined the two. You can’t pay for just the speaking part; the educational sessions are bundled. So I went to most of them. They were good. But mainly inspirational or facts we’ve been exposed to. I don’t need to pay full attention to get what I’m going to out of that.

Conferences encourage this

The Toastmasters conference encouraged people to post in the activity stream of their app. (Like a poor man’s twitter.) They incentivized posting pictures rather than having discussions so the stream wasn’t comment rich. But they clearly didn’t discourage having your phone/tablet out. And they supplied internet. [By comparison there was a no phone/tablet policy during the world championships of public speaking at night.]

Now for the speaker’s side

My first public presentation was in 2011 at The Java Server Side Symposium. (Scott and I live blogged there too). I knew it is common at tech conferences for people to be doing other things while in a session – tweeting, email, coding, whatever. So I gave a presentation at my Toastmasters club called “The Case of the Distracted Audience”. I gave people specific annoying things to do and practiced reacting to them. It helped a lot.

 

 

AWS CodeBuild + Bitbucket – Teams = Epic Fail


Updated 8/19/2017: Amazon has now updated AWS CodeBuild service to support Teams! In other words, in the 2 days since I posted this issue, it has now been fixed. Hooray! I now see my team projects in the list of repositories after linking my account. One minor nitpick though… They sort the list of repositories in the drop-down chronologically, not alphabetically. Since I have hundreds of repositories, that means in order to find a particular one I have to remember the order it was created. Hope they fix this (minor) issue too!


As a user of both Bitbucket and AWS, I was recently excited to hear Amazon had announced integration with both AWS CloudBuild and Atlassian Bitbucket. For those unfamiliar with these two products, AWS CloudBuild is part of Amazon’s suite of code automation CI/CD toolset. This service, along with the full suite, provides the ability to automate software build creation, testing, and deployment. Atlassian Bitbucket, on the other hand, is a large source code repository provider. The AWS announcement means that you can now build projects in AWS using Bitbucket repositories as the source.


Or that’s what it was supposed to mean… Apparently, no one told AWS that most professional software development companies use Bitbucket Teams to manage projects. The new AWS integration is accomplished using an OAuth authenticated sign-in from within the AWS CodeBuild project creation wizard. Unfortunately, after logging in it only allows two types of repositories to be selected: public repositories and those in your *personal* account. Most people using Bitbucket professional use teams and do not store the repositories in their personal account. The result is that no repositories are available for integration.

In other words… it’s broken. One solution would be to authenticate with the team login but Atlassian disabled the ability to login with the team account years ago. Now, Amazon only announced this feature recently, so it is possible they will get around to fixing it but in the short-term it is quite disappointing. While there are other ways to integrate AWS CodeDeploy and Bitbucket, I was looking for an all-in-one solution. In fact, when I recently tried Atlassian’s plugin to integrate one of my repositories into AWS CodeBuild, the web page just froze. Oh well, hopefully Amazon will fix this oversight soon!

By the way, you might ask, “Why I don’t just move my source code repository into AWS CodeCommit?” The answer is simple logistics. If I have hundreds of projects used by hundreds of developers, migrating them to a new repository is not easy/fun. The advantage of having this integration working is that it provides a nice, fluid transition toward migrating to AWS builds, without the commitment of actually transferring any repositories.