CodeSOD: Dating Automation

Good idea: having QA developers who can build tooling to automate tests. Testing is tedious, testing needs to be executed repeatedly, and we're not just talking simple unit tests, but in an ideal world key functionality gets benchmarked against acceptance tests. API endpoints get routinely checked.

There's costs and benefits to this though. Each piece of automation is another piece of code that needs to be maintained. It needs to be modified as requirements change. It can have bugs.

And, like any block of code, it can have WTFs.

Nanette got a ticket from QA, which complained that one of the web API endpoints wasn't returning data. "Please confirm why this API isn't returning data."

It didn't take long before Nanette suspected the problem wasn't in the API, but may be in how QA was figuring out its date ranges:

private void setRange(int days){DateFormat df = new SimpleDateFormat("yyyy-MM-dd")Date d = new Date();Calendar c = Calendar.getInstance()c.setTime(d);Date start = c.getTime();if(days==-1){c.add(Calendar.DAY_OF_MONTH, -1);assertThat(c.getTime()).isNotEqualTo(start);}else if(days==-7){c.add(Calendar.DAY_OF_MONTH, -7);assertThat(c.getTime()).isNotEqualTo(start);}else if (days==-30){c.add(Calendar.DAY_OF_MONTH, -30);assertThat(c.getTime()).isNotEqualTo(start);}else if (days==-365){c.add(Calendar.DAY_OF_MONTH, -365);assertThat(c.getTime()).isNotEqualTo(start);}from = df.format(start).toString()+"T07:00:00.000Z"to = df.format(d).toString()+"T07:00:00.000Z"}

Now, the Java Calendar object is and forever the real WTF with dates. But Java 8 is "only" a few years back, so it's not surprising to see code that still uses that API. Though "uses" might be a bit too strong of a word.

The apparent goal is to set a date range that is one day, one week, one month, or one year prior to the current day. And we can trace through that logic, by checking out the calls to c.add, which even get asserted to make sure the built-in API does what the built-in API is supposed to do.

None of that is necessary, of course- if you only want to support certain values, you could just validate those and simply do c.add(Calendar.DAY_OF_MONTH, days). You can keep the asserts if you want.

But none of that is necessary, because after all that awkward validation, we don't actually use those calculated values. from is equal to start which is equal to the Calendar's current time, which it got from d, which is a new Date() which means it's the current time.

So from and to get to be set to the current time, giving us a date range that is 0 days long. Even better, we can see that from and to, which are clearly class members, are string types, thus the additional calls to DateFormat.format. Remember, .format returns a string, so we have an extra call to toString which really makes sure that this is a string.

The secret downside to automated test suites is that you need to write tests for your tests, which eventually get complicated enough that you need to write tests for your tests which test your tests, and before you know it, you're not writing any code that does real work at all.

Which, in this case, maybe writing no code would have been an improvement.

[Advertisement] Continuously monitor your servers for configuration changes, and report when there's configuration drift. Get started with Otter today!