“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

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