On elegance

This post was published on February 8, 2017

For the last couple of weeks, I’ve been reading up on the works of one of the most famous Dutch computer scientists of all time: Edsger W. Dijkstra. Being from the same country and sharing a last name (we’re not related as far as I know, though), of course I’ve heard of him and the importance of his work to the computer science field, but it wasn’t until I saw a short documentary on his life (it is in Dutch, so probably useless to most of you) that I got interested in his work. Considering the subject of this blog, his views on software testing are of course what interests me the most, but there is more..

Most of you have probably heard what is perhaps his best known quote related to software testing:

Program testing can be used to show the presence of bugs, but never to show their absence.

However, that’s not what I wanted to write about in this blog post. Dijkstra has left his legacy by means of a large number of manuscripts, collectively known as the EWDs (named for the fact that he signed them with his initials). For those of you that have a little spare time left, you can read all transcribed EWDs here.

I was particularly triggered by a quote of Dijkstra that featured in the documentary, and which is included in EWD 1284:

After more than 45 years in the field, I am still convinced that in computing, elegance is not a dispensable luxury but a quality that decides between success and failure.

While Dijkstra was referring to solutions to computer science-related problems in general, and to software development and programming structures in particular, it struck me that this quote applies quite well to test automation too.

Here’s the definition of ‘elegance’ from the Oxford Dictionary:

1. The quality of being graceful and stylish in appearance or manner.
2. The quality of being pleasingly ingenious and simple.

To me, this is what defines a ‘good’ solution to any test automation problem: one that is stylish, ingenious and simple. Too often, I’m seeing solutions proposed (or answers to questions given) that are overly complicated, unstructured, not well-thought through or just plain horrible. And, granted, I’ve been guilty of doing the same myself, and I’m probably still doing so from time to time. But as of now, I know at least one of the characteristics a good solution should adhere to: elegance.

Dijkstra also gives two typical characteristics of elegant solutions:

An elegant solution is shorter than most of its alternatives.

This is why I like tools such as REST Assured and WireMock so much: the code required to define tests c.q. mocks in these tools is short, readable and powerful: elegance at work.

An elegant solution is constructed out of logically divided components, each of which can be easily swapped out for an alternative without influencing the rest of the solution too much.

This is a standard that every test automation solution should be held up to: if any of the components fails, is no longer maintained or is being outperformed by an alternative, how much effort does it require to swap out that component?

As a last nugget of wisdom from Dijkstra, here’s another of his quotes on elegance:

Elegant solutions are often the most efficient.

And isn’t efficiency something we all should strive for when creating automated tests? It is definitely something I’ll try and pay more attention to in the future. Along with effectiveness, that is, something that’s maybe even more important.

However, according to my namesake, I am (and probably most of you are) failing to meet his standards in all of the projects that we’re working on. As he states:

For those who have wondered: I don’t think object-oriented programming is a structuring paradigm that meets my standards of elegance.

Ah well..

"