We all want to know how to build a comprehensive Selenium testing strategy, but first, you have to write a test. Knowing what goes into a bad test can sometimes tell you just as much as what goes into a good one.
Additionally, on the off chance you are trying to sabotage testing efforts at your organization, there are plenty of ways to do that successfully with test automation tools like Selenium. For better or for worse, here are a few ways to construct a really bad Selenium test.
1. Try incorrectly using Waits and Sleeps – Using Implicit Waits and Explicit Waits is a common approach used in Selenium testing to wait a certain amount of time before automating a command. Usually, testers handle them separately to properly test dynamic content, identify elements to interact with, and test in the cloud. Instead, you should try your luck at mixing Implicit and Explicit Waits, which can cause unpredictable wait times or a timeout and cause unstable behavior in your tests. If you want your tests to be even worse, use thread Sleeps all the time to get constant failures.
If you actually want to use Implicit and Explicit Waits the way they’re intended, read our example on testing dynamic web pages.
2. Write a few, large test cases with many chained assertions – First of all, in following best practices for Selenium testing, you want your scripts to be maintainable and reusable. Writing large test cases that cover broad portions of your application make this really difficult. Larger test cases also make it harder to find bugs, which is usually the reason for running tests in the first place. Of course, if you have ulterior motives and want your Selenium tests to work poorly, go ahead and make large test suites. In fact, leave out unit testing completely and definitely do not rely on Page Object Patterns to enhance maintenance and reduce duplication.
If you regret clicking on this page and want to design test cases efficiently, take a look at some better tips.
3. Choose the wrong test cases to automate – Better yet, don’t do any manual testing at all. This way, you can spend your time focusing on finding the bugs in your automation code instead of the bugs in your application. Try your hand at automating new features or an unstable UI and see how much time you can waste. In fact, try automating everything without prioritizing your tests or performing any risk analysis of different elements in the application, and don’t use any data to influence testing.
On the other hand, if you’re having second thoughts about this and want to just look at which tests you’re supposed to choose, you can read about prioritizing automated tests here.
4. Exercise insufficient test reporting – Reporting and documenting is overrated, especially if you’re writing a bad Selenium test. When a failure arises, fix it yourself without finding the root cause of the problem or notifying anyone else on your team, especially the developers. Also, make sure you don’t name your tests so they’re harder to manage for your team, who you should be communicating and exchanging notes with as little as possible. And whatever you do, do not share any screenshots with them — you don’t want to make their jobs easier than they have to be.
5. Execute worst practices in validation – Most of the time, testers will use test scripts with validation to test whether a login page, for example, works or not. However, to build a bad Selenium test you should forget about validating these elements. Or, you can just validate visual elements so the surface level UI seems to be working, but once someone, say, tries to place an order, it doesn’t work because you didn’t query the database.
To learn constructive information about input validation, you could reference this resource, but you’re probably not interested in that.
6. Only test in your browser – If the people using your application aren’t on the same browser, device, and operating system as you, they’re doing it wrong. Either way, without even looking at any analytics, you know they are probably using the same machine. Testing in multiple browsers takes too long and isn’t fun — nevermind the fact that Selenium provides a way to make this faster especially if you do some parallel testing. No one’s going to leave your website because they find one little bug, the page doesn’t load quickly, or it’s completely unusable on their mobile device, so there’s no reason to harp on cross-browser testing.
Also, do not read this guide to parallel testing with Selenium if you want your application to be exclusive.
Selenium is a great tool for automating your tests to get broader application coverage and quicker deployment times, but we can’t assume everyone wants to follow best practices. If they did, they could reference our Selenium guide.
We hope you’re not actually interested in writing a bad Selenium test, but if you are, you should closely follow all of these guidelines. Otherwise, take this opportunity to do the exact opposite of what we’re suggesting.