The Goal
In this series of posts I'm going to show how to leverage clean code principles when writing functional tests.
The Tragedy
I've seen a couple of projects leveraging Selenium/WebDriver API for functional testing. Not even sure if the word "leverage" is acceptable there. For me it looked like "write-only" code and support nightmare in the foreseeable future.
I've been thinking why it is so and couple of reasons have come to my mind:
- Usually these tests are written by QA team. Not all of them are professional developers and have heard about clean code (However I was lucky to see some really brilliant guys in QA automation field though).
- Let's not pretend that our industry does not suffer from incompetent devs as well.
- We often copy/paste from tutorials, ignoring the fact that the purpose of these tutorials is to show how the API is used, not to have perfectly clean code samples.
Regarding the last statement, let's just pickup some random piece of code from Selenium's documentation
It's totally fine for getting started and exploring WebDriver API. If You want to use the code in production, it still needs some additional love though, by providing yet another level of abstraction. In the real life we don't want to see low level API acrobatics, reading the code. We would rather prefer to mess with some business flow at the higher level of abstraction. At least this is my interpretation of some pieces of advice Robert C. Martin gives in his books Clean Code and Clean Coder.
So dear Selenium guys, I didn't mean to show disrespect and I love Your product and I do think Your intention, as I have mentioned above, was to show API not to teach best-practices in these short, little code blocks. Well. Don't know. Write me a hate-mail, if You are still angry.
Posts in this series:
Part 3: High Level of Abstraction