Just a few sections to end this blog post serie.

Just store it somewhere safe

Now I had a few productive days. I could easily do Test Driven Development with the help of the junior DevOps engineer. But I left out one important step in the development: the use of the version control system.

Looking at the numbers I think that Windows 10 is better than Windows 8.

One of the advantages of version numbers is that I know which platform the user used. And which version I have to use to pinpoint a problem in production. Versions are great for code.

Writing code is like making a story for a movie. If I made an error, then I reverted the change using Undo. Most of the time several people are involved for making the same movie story. There are a lot of people willing to pay 8 $ for a good movie. Coming soon to this cinema

Let’s take an imaginary superhero movie. Pete knows a lot of action scenes. After a while he describes a scene to the other crew members:
“And then she flies in the air.”
“Sorry Pete, but Lightning Buzzword Angel cannot fly.”

“But she is called Angel and angels can fly.”
“You’ve got a point, Pete. But not every woman called Angel can fly.”
“So I have to rewrite the whole scene.””
“Sorry dude.”
“It took me weeks to figure out this scene.”
“It is great, but we have to stick to the character.”

“So you just have to start from version 0.3 of the Supermarket Fight Scene.”
“But I also changed the First Car Ride Scene and the Milkshake Scene because of the bruises made by Oval Owl.”
“Wait, you say bruises.”
“Yep.”
“But then I have to rewrite my scene.” Amy remarks.
“And I the Milkshake Scene.”, another writer joins in.

Making a story for a movie is like writing code. If a programmer or DevOps engineer changes a method or function, then this can have severe consequences for the code. The trick to detect faulty code as early as possible. There’s absolutely nothing wrong with that.

Using Test Driven Development or TDD in a proper way a DevOps engineer knows that the added code is right.
Using a version control system she or he can merge the added code with the code in the repository. The result of all unit tests for this file is an early indicator for the quality.
Then the integration tests would be added, merged, and executed.

Now comes the most interesting part. If a release was made in this particular company, all unit tests and integration tests for the whole code were executed. All the tests from previous TDD or Red Green Refactor cycles were reused again. Of course some tests would fail, but the DevOps engineer would set things right. This could be the code or the test or both. And yes, this could lead to refactoring or restructuring code with an eye for maintenance.

After a few days of TDD a new file could be checked and processed in case of positive checks.

Just me and the code

During the coding the DevOps engineer mentioned the Boy Scout’s Rule. Now we were not exactly hiking. Not especially with a flatscreen attached to a laptop. The rule basically states that I should leave the place cleaner than when I came. If I found some rubbish, then I would have to put it into a bin.

In case of software it is all about refactoring and adding missing tests. And that was the case. Missing tests could be considered as technical debt. Yes, tests are technical.

There were still some unit tests missing for other input files. And then old patterns emerged again. I started to write Gherkin files and the DevOps engineer was making them operational. After a few days he started to work on a high prio task and I was still fabricating unplugged unit tests. Then I had to turn my attention to a high prio work item. I put all the unit tests in the version control system and almost forgot them.

Just plug and test

“This takes a few weeks.”
This was the initial thought from my scrum master after the request to plug in the remaining unit tests.

Okay, rhyme after me:
I was high
on supply.

There was one simple way to change his view. I put in the whole file with unit tests and the tests were not executable. So I cut a few times until I had only one simple test left over. It was still not usable.

I needed a default input file. My scrum master agreed:
“It takes some time, but it is worthwhile.”
I slowly assembled a file over a few thousands bytes character by character using an ASCII editor. This took a big chunk of one business day. Then I could code to run my first unit test. And I got a successful test, Green.

I slowly added the other unit tests. I was quite pleased with myself until I had a failing test. Red. This must have been a programming error. I checked the knowledge management system. I was right. Next result of the same test was again Red. Of course, because I did not change it a bit. Pun intended.

I slowed down to a crawl. According to the knowledge management I was right. This time I checked the value character by character. Hmm, time for a chat with the Product Owner.

He listened to my story and told me, that my test was right. So I updated the Knowledge Management System. At last a succeeding test. Green.

This happened a few more times.

That’s it?

This serie described my experiences with Test Driven Development or TDD. For me it was often difficult to stick to Red Green Refactor.  I made a lot of errors on my way. These things can happen. Even for experienced testers there are a lot of chances of being sidetracked.