So, you’d like to start your very own automated testing adventure. And decided to do that by incorporating it into the project you have a dictatorship in. Or in quality assurance, at least.
Fantastic! Excellent! Outstanding! But just a second, space cowboy – before you bravely venture into the automated testing battle against the programmer’s wildest code dreams, you must assemble an appropriate party, consisting of an adequate framework and accompanying language. It’s extremely easy to make the wrong turn and rapidly sink in the technological quicksand, rather than ascend into a higher plane of testing excellence.
First of all – know thy enemy!
Depending on the application – web or mobile – your choice of framework and language will be different… obviously! However, before you do any preparations, you must answer a very crucial, critical even, question – is it worth all that hassle.
That’s right – automating things as a whole is going to take quite some time. And in some cases, it might take a whole lot. If you’re already low on time, the project must be delivered as soon as possible, your coding skills are rusty at best and some kind of a dedicated testing environment doesn’t really exist, then adding that tiny thing called ‘automated tests’ to the whole might prove to be… problematic at best. Remember, these kinds of tests are all cool and good, but there’s not much point in butting them in when you have neither space or skill to do so. All within reason, ladies and gents!
If, on the other hand, you’re feeling pretty confident about the whole thing, and have the opportunity to do so, I’d say definitely go for it! So let’s start with the basics, shall we?
Primo – web or mobile?
While coding the tests might feel similar between these two, there are some major differences and things you should account for. When it comes to web applications, one of the most important aspects is browser compatibility (Edge, Gecko, Chromium engines…), while the difference between supported OS versions and devices is a key thing for mobile apps. As of writing this article, the most popular choices among the web testing frameworks include Selenide/Selenium, Webdriver.io or Protractor, and when it comes to mobile tests – Appium, Espresso or native tests. That being said it’s time to move into…
Secundo – the technology!
Yeah, scary thing, isn’t it? Not to worry, I got your back, bro. Depending on the technology used to develop the application, your mileage may vary:
- Protractor is the best choice for heavy Angular web applications. Selenide and Webdriver.io are more of a general usage, ‘automate-everything’ kind of frameworks.
- Appium is a popular framework of choice when it comes to mobile applications. Espresso or XCUI/native tests are also used for more specific kind of testing (f.e. extensive UI tests in case of Espresso, or as they quote it, “concise, beautiful, and reliable Android UI test“).
Of course, that’s just the tip of the iceberg, as there’s a ton of other frameworks – choices might include Cypress, Puppeteer (both for web testing), or Detox for React mobile apps. Why am I focusing on such a small group of frameworks then, you might ask?
Well, it all boils down to the popularity, community, and support. Because let’s face it, sooner or later you will run into some kind of a problem, critical or not. When it comes to such popular frameworks, there’s a high chance someone has already found a solution to your problem, and even if that’s not the case, your question shouldn’t be hanging too long unanswered. Remember the golden rule – a friend in need is a friend indeed!
Tetrio – the language!
- Espresso is provided by AndroidX Test, courtesy of St. Google, so it’s no wonder it runs on both Kotlin and Java,
- Similarly, the pure XCUITest is Apple’s little special child, so we’re stepping into Swift territory.
Woe is me! What to do, what to do, so many choices, so little time… Tell you what, pardner – the framework and language all depends on your skill and current project. In an ideal world, you’d code the tests in the same language as the application, so you wouldn’t have to worry about the place to stash them or some code review from the developers.
But *this is the world we live in, and it’s not the case in most of the projects. So choose accordingly, choose carefully, choose tenderly, choose meaningfully. As I said before, take many factors into consideration, including your time, skills, knowledge of the platform/project, and potential support from fellow testers/developers.
Last, but not least…
Treat this information above as sort of a guide sign, with a grain of salt and a shot of tequila. Having said that, I wish you the best of luck with your automated testing endeavours! May your code be light and efficient, and time spent debugging minimal, pardner!