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.
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?”
But this would lead to some bad side effects:
“Is 16 the right version number?”
“Would you please bring me a cup of coffee?”
“Would you please transfer 1 Million Euro to my bank account?”
[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?”
[Half hour later]
“I would like to order dinner.”
[Blank face] (Red)
“Did you understand me?”
[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.