Earlier this year I started working on a new video course, Selenium WebDriver Basics for Java. After a couple of months delay, I have been able to start working on it again. The following are samples from the Getting Started section.
I recently saw a post in the Test Automation community on LinkedIn suggesting that we should stop writing custom frameworks. The reasoning behind the suggestion was that it was time consuming to reinvent the wheel when there was an Open Source project, RedwoodHQ, that already had everything you need. Like most of the commenters, my first thought was that I was just reading a sales brochure for another “silver bullet” automation solution. The author, however, insisted that it was a sales pitch since his framework was free and he just wanted to raise awareness of a new tool that is available to the community.
I have long been a proponent of developing one’s own framework to build understanding of the underlying operations. In some ways it’s like Jedi training, you might start out using a lightsaber you were given but you will not become a master until you have constructed your own. In my experience, using pre-existing frameworks can limit an automator’s growth by obscuring the inner workings. Some frameworks will also limit a user’s ability to perform tasks because the developer didn’t consider that use case.
With that in mind, I decided to look at RedwoodHQ and see what it actually is. It wouldn’t be fair of me to write off someone else’s work without at least taking it for a spin. After reading a bit more about it, I downloaded the application and set it up on a VM. The installation process was smooth and I was connected to the web interface and poking around in the sample test in minutes.
For someone with very little knowledge of Selenium WebDriver, they could develop a test with RedwoodHQ right out of the box. They may even be able to begin learning by looking through the action example code. I wouldn’t, however, recommend keeping the original actions in the long term. If for no other reason, they need to be replaced because the current Selenium code uses hard sleeps and possibly relies on implicit waits.
With that said, don’t write off this framework yet. You’ll note that I recommend replacing the actions. This is extremely easy to do using the built-in web IDE and you can drop in any jars you like to use with your tests. This means that if you have built your own framework, you could compile it and reference your own classes and functions within RedwoodHQ. I am currently considering doing just this.
The efforts I have put into my personal framework have been focused on building functions around Selenium WebDriver to make developing page/component objects easier and by extension making the tests easier to write. In this way, I was not limited to using a specific test framework (although I tend to use TestNG most often). I have now realized that unlike other automation tools and solutions, RedwoodHQ operates at the same level as a test and reporting framework and will not interfere with working at the lower levels.
Since this is only an initial review, I can’t speak to how it integrates with a CI environment but I am willing to give this tool a chance. Once I have adapted my Selenium framework to RedwoodHQ, I am considering submitting it as a replacement for the existing actions. I believe the tool would benefit from having actions that utilize explicit waits and provide more than just basic functionality.
The take home from this is that I learned that RedwoodHQ is not another “silver bullet” automation nightmare. It is a test development, management, and reporting framework that won’t limit you to working within their methods. My intial opinion is “Well done!”
In 2016, I published my first course—Automated Testing Using Selenium WebDriver—on Udemy. With that course, my intent was to provide an intermediate level introduction to Selenium WebDriver. I decided to further differentiate it from other courses by working in both C# and Java. While this succeeded in showing that it is easy to apply the concepts taught in multiple languages, I fear that it could be confusing for students that are not experienced in development. This is where my new course will come in.
Students will be required to have a basic understanding of development concepts and Java, but I will be covering the additional technologies and concepts used in greater detail. From installing an IDE and using Git through running tests using a Selenium Grid, my new course will provide you with the foundation you need to become successful in your automation endeavors.
Topics to be covered include:
- Installing an IDE
- Installing browser drivers
- Creating your first Selenium WebDriver test
- Locating web elements on a page
- Waiting for web elements
- An overview of the Page Object Model
- Running tests against a Selenium Grid
- Local Dockerized
- Sauce Labs
- Testing Bot
- Other tips, tricks, and concepts for writing great automation
The following is a sample video showing how to setup a Selenium Grid using Docker and Docker-Compose on an Ubuntu virtual machine. This lesson will be part of the Selenium Grid section of the course.
When testing with Selenium WebDriver, it usually becomes necessary to need access to multiple drivers simultaneously. This may be for running tests in parallel or performing cross-browser testing. One possible solution to this is the use of a Selenium grid. The following video from my course on Udemy explain what a grid is and how to configure one for use with your tests.
I was contacted recently by someone looking for assistance in automating a page that uses ReCaptcha. Since there are only two reasons for doing such a thing, application testing and SPAM, I offered the following information.
First off, the purpose of a captcha is to prevent bots/automation from being used to access an application. This means that if you can successfully automate the captcha then that would be a failed test and the captcha application should be replaced with one that hasn’t been beaten.
With that said, the question of how sites that implement captcha can be tested with automation remains. This cynical answer is simply, “you can’t”, but this is neither true nor acceptable. The correct answer is to plan ahead and work with developers to implement a test mode that can be toggled securely. This will allow the automation test environment to bypass the captcha and test the meat of the application, while providing confidence in the security of the production site after manually confirming the integrity of the captcha.
After some thought, the manual testing could be skipped (not recommended) if the test mode was built into the captcha module such that when implemented, it would always provide the same challenge. This would allow for verifying the captcha functionality is working and be able to successfully test the remainder of the application as well. The issue with this would be making sure it was not possible to put the captcha into test mode through injections or other trickery in production.
I would be remiss if I didn’t warn my fellow testers that there are methods available for beating captchas such as OCR implementations and some specialized API services. These should be considered when performing your tests and assessing the security of an application. I am not going to promote any of the sites here since I don’t want to make it easier for script kiddies to get their hands on them. They were easy enough to find without my posting links last time I checked.
After just over a month of planning, recording, and editing, my first Udemy course, Automated Testing Using Selenium WebDriver, has been launched. This class covers the essential skills needed to begin developing tests and other automation using Selenium WebDriver.
The topics include:
- Analyzing a web page to prepare for automation
- Identifying element locators
- Implementing the Page Object Model
- Deploying and connecting to a Selenium Grid
- Developing a universal framework to expedite any automation project using WebDriver.
To celebrate the launch of the course, we are offering a 50% discount to the first 200 students using this link
The quality of anything you build is going to be a reflection of the underlying infrastructure. This fact applies to temples and test code alike. You wouldn’t build a cathedral on a shoddy foundation, so why would you be willing to build a test suite using fragile coding practices?
Good coding concepts and practices are not just for use in final applications. Those same ideas should be used when developing tests that will be used to confirm the application’s functionality. I recommend skipping the unit tests of the tests though, you do not want to go down that rabbit hole.
When developing test suites, it is a good idea to utilize encapsulation and abstraction. This will simplify the building of tests while simultaneously increasing code reuse and reducing the fragility of them. One method to achieve this is through the use of page objects. Continue reading Using Page Objects
First Things First
For those unfamiliar with Selenium, it is a suite of open-source browser automation tools consisting of three main products: Selenium IDE, Selenium Server, and Selenium WebDriver. Selenium IDE is a Firefox plugin that can be used to record and playback tests. Selenium Server is a java application that is used to control browsers on remote machines and/or to create what is called a Selenium Grid. The final component of the suite is Selenium WebDriver, which is a browser automation API designed to create tests or perform other required tasks. Each of the suite components serves a specific purpose in a web tester’s toolbox although all of them may not be needed within an organization.