Being a test-tooling nerd, I had to learn more.
This is what I discovered.
First, frequent readers of my articles know that I generally recommend that you use an existing framework before creating your own.
So the first question I asked Adrian was, why did he feel the need to create yet another automation framework?
The short answer was that his team couldn't find an open- source tool with the features they needed. For example:
- A tool that can be used by people of all skill levels
- A tool that can do seamless, distributed testing that can run test steps between multiple applications and machines
- A tool that works with source control
- Something with a robust, extensible design
Design Goals for Creating OpenTest
The creators of OpenTest made it very easy to extend, and it can be done without the need to change anything in the core test framework or tool.
It's merely a matter of creating a Java class that derives from some base class that OpenTest provides. You can then override one method with whatever you want. Because of this, it's effortless to extend.
The example Adrian gave me is that they have a hard-to- automate, point-of-sale desktop application (POC) with custom controls and was able, using OpenTest, to create a test scenario against it.
As we talked about reuse rather than starting from scratch, he also mentioned that his team looked to the market for libraries, and in particular open-source libraries, before creating new functionality.
Because Selenium and Appium are two libraries that are proven, reliable, and are the undisputed leaders in their segments, so they used them in OpenTest.
For API testing, because Java already has quite a few libraries that handle Web service tests, they went with the Apache HTTP client library.
Why Use Java Over, Say, Python?
One other important decision that Adrian had to make at the start of the project was which programming language they should use.
They ultimately chose to go with Java because it's a mature language; it's basically the “language of test automation.”
He went on to say that he knows different people have different opinions on that, but if you take a look on StackOverflow, I think you’ll find it's much easier to find answers and help if you're using the Java Language.
This is why they chose to go with Java. (For the record, I like Python. ☺)
Cross-Platform Automation Support
Another criterion for their framework was that it needed to be cross-platform and support as many devices and scenarios as possible.
If you look at the architecture of OpenTest, you'll find that there are very few test automation scenarios that are not supported. As long as a device can run Java, that device can be used as part of your distributed test—and that happens seamlessly.
This is why it's very straightforward to write a distributed test with OpenTest. And it’s just one of the unique features that set this tool apart from some other frameworks.
No Coding Skills
One of the claims of OpenTest is that it requires no coding skills.
Here is an example of what an OpenTest script would look like:
What the OpenTest Framework Supports
If you've read this far, you’d probably like to know what else OpenTest supports. This is the list that appears on their website:
- Web testing leveraging Selenium WebDriver.
- Mobile testing leveraging Appium
- API testing with Apache HttpClient
- Keyword driven testing
- Parallel Testing
- Distributed Testing
- Data-driven testing
- Source control friendly
- Cross-platform support
Getting Started with OpenTest
Currently, OpenTest has 130 stars on GitHub.
To get a feel for it, let’s see what it takes to get started running tests.
During installation, you get three main directories: The server, actor and a test-repo.
- The server is used for the web interface where you can run and view test results:
- The actor is a Java application used for running the test and communicating results to the server:
- The test-repo is a directory with some test example to get you started:
Once the server and actor are running you can begin your test session.
- In the OpenTest server click on the Session> Create Session from Template.
- Click on the Quick start tests option
- Click the Create Session button
- The test should run and pass.
- Click on Quick start tests to view results
This should be enough to help you start experimenting.
If you have lots of tests that require executing across multiple machines, networks, and technologies, OpenTest might be worth checking out.