BDD and Selenium
My company’s engineering center of excellence has begun to promote using Behavior Driven Development (BDD). The good thing is that most of the teams have embraced BDD as part of their development process; the bad part is that I’ve noticed that most of the BDD tests are UI tests using Selenium.
I won’t go into a rant on how BDD is not an automation framework – my main point is that as an automation engineer, I believe we should try to avoid automating the user interface as much as possible.
Selenium is awesome/don’t use selenium
This sounds like a Zen koan (a succinct paradoxical statement or question used as a meditation discipline for novices). Yes. Selenium is great and can handle many web browser automated tests, but like any GUI automation tool, it has the three GUI automation causes of suffering:
It’s slow to run
Hard to maintain
And hard to make reliable.
The goal should be to reduce the amount of Selenium test you create not more.
Before using Selenium Ask Yourself Why
Before using Selenium you should ask yourself why. Is there a better, faster, more reliable test type that can be used?
Browser UI automation should not be the only type of testing you are doing. You should try to test more things in isolation rather than a full blown end to end UI browser test. Touch the UI as little as possible. Focus on unit and service/API level test first.
How Google Test’s Software
Google’s automation rule of thumb is: 70% should be unit tests, 20% should be service integration testing and only 10% should be full blown GUI automation.
If you can test a feature without having to render a browser, you should automate that first.
Google Testing Secrets Reveled
So if you are responsible for maintaining test automation scripts your new mantra should be: Selenium is awesome/don’t use selenium <–tweet this. Funny, since this tip was offered by more than one of the main committers to Selenium (including Simon Stewart the creator of WebDriver and project lead) at the Selenium Conference in Boston this year!