Modern Software Engineering – Part 2: Testing

“If debugging is the process of removing software bugs, then programming must be the act of putting them in.” – Edsger Djikstra

Photo by John Barkiple on Unsplash

Writing automated software tests is like playing a game of telephone with yourself – you’re the only person you can blame when you misunderstand what the message is. It’s hard enough if you’re writing tests for your own code, but consider the case when you’re writing tests for code that someone else has written that wasn’t being tested in the first place. Now it’s like trying to understand what the message was from a piece of paper that’s been washed in blue jean pockets… three times!

That’s for tests that are written after the code being tested has already been written. Now consider the practice of writing the tests first – it’s like playing mastermind with yourself, by first writing some plausible-looking specification or test the ensure that the solution you will write is going to “do the right thing”. But if you took computer science, then that sounds very much like solving the halting problem – only worse because now you need to prove not just to yourself but to the compiler/interpreter that the thing you want it to do is the right thing.

So why has testing been such an integral part of the modern software engineering practice for the last 20 years – whether it’s test-first or test-last, we professional software engineers still need to think about how the software is tested and verified to meet the requirements.

Introduction

It’s story time again.

Last time in Part 1, I wrote about how I learned the hard way how to design systems to suit modern scaling, reliability, availability, maintainability, and security requirements. Designing a solution only goes so far, because at the end of the day, the solution needs to be implemented – sometimes, it has to be done by a team of people or multiple teams of people.

You can imagine that the coordination of efforts across teams is going to be a major source of issues, but is there something we can do to reduce this burden? In comes automated testing – especially the kind that specifies behaviour instead of tests the implementation.