Back in 2011, I approached Rob Lambert at the Software Testing Club on a small series, packed into a narrative format as I wanted to try that out. Rob decided to run that series on the Software Testing Club back then, and I had some fun writing it. Skip forward 11 years, and the Software Testing Club no longer exists, it’s been a while since I have been in touch with Rob, yet I figured, let’s see how this series aged over the years. As a sort of throwback Friday for myself, I will publish the entries on a weekly basis, and read along with you. I think I ended up with eight chapters in the end and might add a reflection overall at the end. In case you want to catch up with the previous parts, I published these ones earlier:

• Chapter 1: Session-based exploration

Chapter 2: Facing the Business with Automation

As Eric and Peter came into his office, John turned to them.
“Hi Eric and Peter. Eric, you wanted me to show our junior some test automation?”
“Exactly. He stayed the morning with Jennifer and was eager to see something more ‘interesting’.”
Eric and John laughed, Peter smirked sheepishly.
“Alright, give me two hours with him.”
John showed Peter a web-page which looked quite similar to the product he tested in the morning.
“On this user interface we write down what our automated tests shall exercise later on.”
Peter was amazed. “Did you build the product again with a testable user interface?”
“Sort of. We have some mechanisms to express expected values and exercise them in the system we’re testing. We just need to write it up in the right fashion. Later, we’ll automate these tiny pieces and bits to interact with the system.”
“Ok, I recognize this part of the system from my session with Jennifer this morning.”
John and Peter worked through the web interface. John answered Peter’s questions patiently. Peter suggested to incorporate some of the tests he had run together with Jennifer. John was delighted by the enthusiasm the junior spread out.

After John had shown Peter some of the tests in the web interface, he started to switch topics.
“Now, let’s move on to the automation part.”
He switched to another screen. Peter immediately recognized the IDE from his university courses. There was a green bar indicating that his unit tests passed.
“Ah, you ran the tests through the unit test runner.”
“No. They are run directly in the web interface.”
“But, … that green bar… that’s from a unit test run, isn’t it?”
“Yes, exactly.”
“So, you’re running the unit tests from your developers then?”
“Hahaha, no, these are the unit tests for our automation code.”
Peter struggled. “So, … you write unit tests… for your tests?”
“Yes, of course. For complex test classes, we write unit tests, so that we remind ourselves about our thoughts the next time our paths cross them.”
“So, you test your tests?”
“Yes, does this sound unusual to you?”
“Well, I don’t think there was a course mentioning this in university.”
“Yeah, true. We learned this the hard way. A few years earlier we tried to automate some of our tests. We bought a capture and replay tool, which was able to record your interactions on the screen, store them on the hard-drive and play them back later.”
“Oh, why don’t you use it any more? This sounds terrific.”
“Well, the automated scripts couldn’t keep up the pace with the development. Just move a button two pixels to the right, and boom, we were spending the weekend capturing the tests again, or just adapting them to the new UI layout.”
“Oh.”
“Exactly. Now, we automate our tests using a programming language. For the more complex classes we use test-driven development. Just as our developers. We evolve the functions. See, this test we wrote earlier. Let me exercise it.”
Back on the browser window John hit a button on the web interface and parts of the page got coloured yellow, red, and green.
“You see this yellow bit here? It indicates a missing functionality for the test automation. This one we’re going to develop now.”
He pointed to one of the new tables in a test that Peter came up with.
“Alright, but test-driven development? I heard about that, but never practiced it.”
“True, I assumed so. I propose we use Ping-Pong-Programming.”
“Ping-Pong-Programming? Where do I get my racket?”
“Hahaha, no, let’s write down some of the things our new class will be doing.”

John fetched a piece of paper from his desk. Peter was struggling.
“But, … you said we were programming.”
“Yes, but we need to think about what to program before starting to do so. Typing is not the bottleneck, otherwise we would simply get ourselves faster keyboards.”
“Ok, so, what do we note down on that paper?”
“We denote our charter for the class and the TDD session. We think up-front about what our little class here shall do and write it down as examples. These examples will then guide us through the implementation.”
“Ah, I start to understand, how about …”
Peter and John started to brainstorm about the functions they would like to see in the class.

“Now we have settled our charter. On to the fun part. Let me write down the first test here for you.”
John implemented a tiny piece of the unit test code, hit the test button, and the green bar turned red indicating a failing test. John passed on the keyboard to Peter.
“Now, your turn. Make the test green.”
“Ok, let me think. We need…”
“Ah, no, just make that tiny piece green. It does not need to do more. We’ll come to those parts later.”
Peter had a big question mark in his eyes.
“Just write down the simplest implementation you can think of that makes this test pass.”
“But, … that would be returning the expected value. Isn’t that cheating?”
“It would be cheating if we left it as is by then, but we aren’t going to do that.”
Peter slowly erased the code he had started with and filled in the return statement for the expected value. As the test turned green, John striked through the first item on their charter.
“Now, write a test for the second item on our list and handle the keyboard back to me, so I can turn it green.”
Peter did as he was told. John quickly implemented just what was needed to make the test turn green. Then he did something, which Peter had slightly heard of before: refactoring. John polished up the code, wrote the next test and handed back the keyboard to Peter.

After a few more keyboard exchanges, John and Peter had worked through the list. Peter felt unsure. The implementation part was more fun than work, and Ping-Pong-Programming seemed to be a great thing.
“Now, we should be able to exercise this test in the browser.” John hit the button on the web interface again, and this time the parts of the tables turned all green. “Ok, great. Let’s take a break.”
“So, that’s all about automation?”
“Yeah, exactly. Not quite what you expected, hm?”
“Yes, actually, it felt more like fun than like work.”
“Exactly this is why it works.”
After a short break John and Peter got back to the parts still missing in the automation code. At the end of the first afternoon, John started to execute all automated tests. When they saw them all passing, he checked in everything Peter and he had worked on.
“Now, it’s time to get home, kid. In the night these tests will be executed against the latest changes in the version control system. Tomorrow we should be able to see some progress then.”
“Ok, thank you. This whole afternoon passed in no time.”
“Before you head home, let’s sit together with Eric for a debriefing.”
“Alright.”

Eric was already awaiting Peter und John.
“So, how did the non-boring part turn out?”
“Oh, it was really great. Time passed quickly and I feel like we made a bunch of progress.”
“So, you wrote down some of the tables, and automated them?”
“Yeah, exactly. John showed me something called… erm, table tennis… no ping-pong programming. That was really great.”
“What else did you learn?”
“Tiny steps with quick feedback are crucial. We took tiny steps with automating the web-browser based tests, and took even finer steps with the unit-level tests. Having the quick feedback from the automated parts really helped.”
“Great. Tomorrow let’s see if your new tests also pass against the latest build of the software. Our Continuous Integration server will take care of that over night.”
After Eric finished the debriefing, Peter went home, constantly reflecting over the day.