Monthly Archives: July 2018

Some readers might have noticed that Gherkin is used for unit tests. And this might be strange or unsettling. For me it was normal. In this company the DevOps engineers worked that way. It worked, so as a tester I had to put in more effort to find bugs. Sure no problem.

Me programming

My first action was to write a test to check a business rule for a valid observation date. While I was typing, the Integrated Development Environment aka IDE suggested several options like a search engine like Google. But observation date was not known. So this sentence was highlighted in red. Syntax highlighting is also handy in programming. I don’t mind that at all.

With the help of the DevOps engineer I wrote code in Java, so the IDE could use observation date in Gherkin. The code could be executed, but the test failed. Hey that was bad.

“Now I write the code.” was my next thought.
Of course there was no code, so the test should fail. Definitely Red.
This would be fun.

I had to program in Java and I remembered that the junior DevOps engineer had some useful shortcuts. I looked in the IDE and found the option in a sub menu to add a method. I gave it a name and – yes – I got an empty method in the right class. Now I had to fill in the blanks.

Me writing Gherkin

Months earlier I had written several Gherkin unit tests in the knowledge management system. There were two things wrong with this approach. The tests were not used, so I was high on supply. In plain English I had made something which was not used. On a scale of time it was a waste of time.

The other thing was that it had a web interface. The syntax highlighting did not work. I could make things bold and indent texts, but that slowed me down too much.
The result, the code, was not easily readable.

The dates were in the following format DDMMYYYY. This is programmer s’ language for Day in 2 numbers, followed by Month in 2 numbers, and finished with Year in 4 numbers.
So April 1st 2001 would be written down like 01042001. 01 is the first day of month number 04, which is April. 2001 is of course the year. It is easy to pick good dates like

01042001 (first day of the month),

31032013 (last day of the month), and

29022000 (leap day).

I picked some wrong dates on more rational grounds:

07142011 (for the Americans July 14th 2011),

20132007 (20th day of the 13th month), and

1jan1998 (January 1st 1998 in a hydrated date format.).

After writing date tests for one date field I noticed a pattern. I would check on all these dates again for other dates like expiration date. I thought I was smart. I just copied all the observation date tests and replaced ‘observation date’ by ‘expiration date’. I even copied the tests to a special text file, so I could save time. But I was wrong!
Please read on.

Me at the keyboard again

So I was programming unit tests and on my side was a junior DevOps engineer assisting me. I could finally write a test in Gherkin. In a separate window I opened the knowledge management system. I picked the first right date 01042001.
“Why do you pick this date?”, my personal DevOps engineer informed.
“I want to be sure that the right date is accepted.”
A nod followed by:
“We use Joda-time for that.”

I heard: “Yoda time”
It was not possible for me to link a lightsaber wielding big pointed eared green creature with programming.
“Joda-Time checks on valid dates, so you do not have to test them.”
Java 7 was not safe enough for dates and some programmers made Joda-Time. That saved me a lot of time.

So I only had to test on the wrong dates. Easy. I added tests, which succeeded. Green.

There was a `but` coming up.
“You can skip that date.”, while the DevOps engineer referred to ‘1jan1998’.
“Characters are not allowed in the date. ”

The next morning the DevOps engineer showed me a neat table:
Given the file has observation date <date>
When the file is read
Then the file will not be processed
Examples:
| date |
| 07142011 |
| 20132007 |