Category Archives: Programming

Being Sidetracked – Part 4

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 |

He had improved the test code considerably. Refactor. I forgot to use DRY, Don’t Repeat Yourself.

My scrum master said that it was important to know how to program. This way I could structure my tests in a good way.
But the worst was still to come.

To be continued.

Being Sidetracked – Part 3

“At the moment I am writing a serie of blog posts about Test Driven Development.”
I looked to the recruiter. “You can understand it.”
I moved my view to the manager: “You can also understand it.”

Sticky note: let’s stick to the DevOps engineer.

Vegetable As a Service

The DevOps engineer wrote the unit test in Gherkin. The main advantage is that this language is easy to read. Have a try.
Given the version number is 15
When the file is read
Then the file will be processed

It is also easy to write. This example is in English, but it is also possible to use plain Dutch.
Gegeven een versienummer is 15
Als de file wordt gelezen
Dan wordt de file verwerkt

This is easy for people in Dutch companies. Nothing is lost in translation. It is easy to digest. No mindreading skills are needed.
The tool Cucumber provides a way to translate these sentences to a programming language like Java. A programmer has to code, how the sentences are translated.

When this little story is used by the computer, Java is used to execute this test. Yes, it is time for another cup of coffee. Which is the symbol of this language.

There are of course some people, who want to add some details to it. And yes, this is necessary.
Feature:
As an administrator I only want to process the right file list_20180525.txt, so that marketing managers can still process the data and generate reliable reports.

Background: file A

Scenario: 15 right version number
Given file A has version number 15
When file A is read
Then the file will be processed

Scenario: 16 wrong version number
Given file A has version number 16
When file A is read
Then the file will not be processed

All the text is put in 1 file, so all tests are nicely organised. A very important detail is, that file A is a complete valid file. This takes some time and some byte shuffling, but it is worthwhile.
So after 2 cycles of Red Green Refactor two scenarios were added in a feature file. These scenarios could be executed individually or in a group.

Then the cycle continued. The latest test was used frequently to assure, that the code was modified in the right way. The previous tests were used to assure, that the quality was the same. This led to a massive set of tests.

What’s next?

The DevOps engineer looked for the next feature to program. I saw an impressive table of valid values and validation rules.
“Do we have to test all this?”
“No”, he answered.
I could not believe my ears. There were so many places where things could go wrong.
“We will only test things, which can cause problems in our software. [The postman] will check the data.”

I visualised the data flow in my mind. There was a sender, which gave a file to the postman. This program would check every byte of the file. After a successful check the postman would deliver the
file to the receiver or the program under development. In the past I heard, that sometimes some things were not properly checked by the postman. With the speed of computers today extra checks can be done very fast.

The DevOps engineer continued:
“If data can cause problems in the software, these are checked.”
Version number is a good one. And of course begin date and end date of a period are also important.

Another cycle to start

This looked so easy.
It was like the junior DevOps engineer had some mindreading skills.
“Now you try.”
I was silent for a moment.
I repositioned myself after the keyboard and the mouse.
Pair programming. The real stuff.

Okay, let me start.

Read mindfultester[dot]com
My answer in a job interview

To be continued

Being Sidetracked – Part 2

A few weeks ago I told my wife about the picture for this blog post serie. “There is a red light. And a green light. The rest of the picture is fuzzy.” It was about “Red Green Refactor”.

“You should [tidy up with known product name] the picture.”, she suggested.
I liked the fuzziness. This was about Refactor.

Second cycle

We had just finished the first cycle.
The DevOps engineer wrote another test. Ready for the next modification.
O yeah. Test Driven Development.

Let me sanitise me this example. This means so much like “all confidential information is changed”. On purpose. Everybody happy?

A file can only be processed, if the version number is 15, 20, or 31. After the first cycle every version number was accepted. The first test was:
“Is 15 the right version number?”
“Yes”
But this would lead to some bad side effects:
“Is 16 the right version number?”
“Yes”
Or worse:
“Would you please bring me a cup of coffee?”
“Yes”
What about
“Would you please transfer 1 Million Euro to my bank account?”
[Upset face]
[Whispering] “You are supposed to say: “Yes”.”.

Okay, back to the real example.
The first test was to determine whether 15 was a right version number.
The DevOps engineer added a second test to determine whether 16 was a wrong version number. He performed the last test and 16 was a right version number. This was wrong: a failing test. Red.

The DevOps looked at the invalid value and added a single condition to the code. If the version number is equal to 15, then return “Yes”. Otherwise return “No”. The second test was executed again: this time 16 was a wrong version number. This was right: a succeeding test. Green.

The code was very simple, so no refactoring was necessary. Refactor.

Then the DevOps engineer executed all or both tests and they were both correct. The second cycle was over.

While blogging, I realized old patterns of thinking were still present in my head. Let me answer a few questions.
Question 1: This code is so simple. Why do you need to write all the tests?
Answer 1: During every step the DevOps engineer can use the written tests to determine, whether the code is still good. This is especially handy for complex code. Failed unit tests can point to where things go wrong.

Question 2: why did the DevOps engineer not add a second test for valid version number 20 or 31?
Answer 2: it would not lead to failing test. In other words the code would not have to be modified because of this test. At that particular moment he would have written a redundant test. That is a waste of time.

Question 3: Do all these tests take a lot of time to execute?
Answer 3: No. The tests are unit tests and fast enough to execute. The hardware has been improved considerably, so these tests are executed within a fraction of second.

Question 4: Would you please continue?
Answer 4: Sure. No problem.

In the previous blog post I wrote about my disability to speak Chinese. That is quite confusing, because I look like a Chinese and not like a Dutchman.
Small recap with the restaurant in China:
“Do you speak English?”
“Yes.”
[Half hour later]
“I would like to order dinner.”
[Blank face] (Red)
“Did you understand me?”
“No.”
[I opened the menu.]
[Waitress approaches me.] (Green)
[I just ordered the dishes using my fingers and the menu.] (Refactor)

What I actually did, was trying to find other ways to order dishes. I could have written down my order, but the waitress could follow my hands. So no refactoring was needed.
No is unpleasant answer, but a lot of frustration was avoided. At least I understood, why hand sign language for numbers was included in the pocket book for frequently used phrases in Chinese.

To be continued.

Being Sidetracked – Part 1

Every story has an expiry date.

So I have to hurry up.

While the junior DevOps engineer was programming aloud, I paid attention to all the steps he took. He used Test Driven Development. It is a cycle of Red, Green, and Refactor.

A small recap: he first made a tiny test, which failed. Red is a favourite colour for failing. Then he made code to let this failing test succeed. Green is that other favourite colour for DevOps, testers, and especially managers.

Then he refactored the code. The code became more maintainable and readable. Even for a tester not fluent in Java.

The first test was to check, whether a business rule failed. He wrote only code to let the test succeed.
Before I could think, the method was ready. It had only one return statement with 1 fixed value.

But this would only be the case for very specific situations. I showed my disbelief and he answered that the code had to pass the new test. Right, you are right.

This was a strange situation for me as a tester with a traditional background. Tests should be executed after the implementation and not before. Somehow my brain had pushed the theory about TDD aside. It felt so unnatural to me that I unconsciously switched back to Program First Test Next.

Anyways, the DevOps had a quick look to the code. I did not think that this could be refactored. One line single statement cannot be refactored.
Yes right again. The first cycle was finished. Red Green Refactor.

A return value from a method is like an answer from a human being. What the DevOps basically asked, was: “Is this value right?”
And the method would always answer with “Yes.”

This was strange to me. Now I realised, that this was the most minimal addition to the program.
Without a method the code would have be repeated multiple times and maintained at the same number of places. A recipe for disaster.

Aw I forgot to look in the right low box in the left corner in the room under the stairs.

Now programmers have a small heuristic for this one:
DRY. Don’t Repeat Yourself.

The fact that the answer was always “Yes”, bothered me. While blogging I remembered asking a restaurant in China, whether they could speak English. The answer was “Yes.” My wife and I were delighted until I ordered. O no.

To be continued