What's in a name?

by Thomas Zeeman, May 6, 2020

Those that have followed this blog for some time, know that Trifork Amsterdam, and especially its precursors, are not unfamiliar with challenges when it comes to naming.
Now that we have been in the larger Trifork family for some time, it does look like our corporate naming challenges have settled down quite a bit.

That does not mean that we are completely devoid of naming issues though. But these days they typically come from having to name methods, fields, classes and other things related to a typical software development process.

I was reminded of that a little while ago when I was working on a project where we used Cucumber to create a functional regression test suite. For those that don’t know what that looks like, here’s a short example of a feature file:


 Feature: Subscription management
   Tests all things subscriptions
 
   Scenario Outline: successfully subscribe to the <magazine> for (<term>)
     Given a reader has not been subscribed before
 
     When the reader subscribes with a start date "<startDate>"
 
     Then the reader should have a subscription with start date "<startDate>" and end date "<endDate>"
 
     Examples:
       | magazine       | startDate  | endDate    | term      |
       | Donald Duck    | 2019-09-04| 2020-09-03| 12 months|
       | Lego Star Wars| 2019-10-25| 2020-04-24| 6 months|

As you can see, this is almost like a piece of poetry; and I don’t mean the Vogon kind… Readable and you can almost grasp its meaning, as a layman.

Now, on this project, we had a lot more of these feature files and scenarios. So many, that no one person knew each and every scenario by heart. A typical software development project therefor.

At some point, while looking into some bug report where I had to run some of these regression tests I noticed that there was a mismatch in information. The summary that showed a number for the total amount of scenarios that were run, did not match what I counted in the test suite that I was running manually. Granted, it took some time to notice this. The bug was somewhat elusive until that point.

Digging into this I got more and more puzzled until I remembered a previous experience with JUnit 4 on another project a long time ago. There too, we had test methods with the same name being used in different test classes. Due to some reason, we had written some of these test classes such that the execution of the test methods mattered. (I know, I know, bad practice. Sue me, I’m human too. Or so most people seem to think at least.) If we ran the test suite completely, it would sometimes fail in such a way that we knew the order of test execution was not the same as the order in which we had defined the methods in the class. Running the test in isolation would always cause a green bar to show up in our test report.

When debugging that issue, what we found back then, was that JUnit 4 would use a rather peculiar ordering of executing the test methods. Whenever it would load a class and scan the test methods to execute, it would order them in the same order as they appeared in the class, albeit with one small exception. If the method name had already been seen in another test class during the same run, that method would be listed first, before the rest of the methods. In effect, the order could change from

testA
testB
testC

into

testB
testA
testC

No need to explain that if testA sets up some data used in testB the second ordering is going to have some issues.

The fix, in the end, was to rename the methods to be unique across the entire test suite.

With that memory having resurfaced, I went over the entire test suite and, sure enough, I found several scenarios to have the exact same name. After renaming them, the count showed the expected number. Incidentally, it also fixed the test failure.

It has been some time since we’ve seen cars or computers named after their inventor’s child, and hopefully, no one that entered the IT workforce this millennium named variables after a loved one. Instead, we should strive to find the true name for objects and actions we describe in our code. For a true name gives the object meaning, purpose, power.

But, as Ursula K. Le Guin so eloquently wrote in her Earthsea saga, if you take a boat to a faraway land it may fall apart into the planks it is built of, as its true name no longer has what it takes to hold it together. And so it is in software too, because where in one context a name may mean one thing, in another it may mean something different or have different properties.