PhantomJS is a lightweight headless test runner which is perfect for command-line-based testing. What is PhantomJS? It allows us to access the browser’s DOM API. After all, PhantomJS is still a browser without the GUI skin. It is suitable for local development, version control pre-commit hooks testing, and as part of your continuous integration pipeline testing.
The headless test runner WILL NOT be a replacement for Selenium functional testing. The idea behind a command-line base testing suite is that it will provide fast feedback for a deployed web application without spinning up a browser. It is critical to set a standard where developers naturally execute static code analysis, unit tests, server spec tests, and PhantomJS tests in a local development environment before creating a pull request. The next section will help you understand why a well-defined cloud testing strategy will reduce web application bugs in production.
Cloud Testing Strategy
A major component of cloud platform solutions is that all of the code goes through the gauntlet of testing before merging a pull request into the master branch, and before pushing changes to production. We need to prove that the code deploys the web application correctly before we start using it in the cloud staging and production environment. It’s much easier and cheaper to catch and troubleshoot issues locally, as opposed to having production servers go down or affect the user experience.
Thanks to configuration management tools, we can use Chef, Vagrant, and VirtualBox to spin up a web application locally and begin testing changes before even creating a pull request.
The general strategy is to make testing easy for developers or whoever performs web application code changes. How do we make it easy for developers? The best testing tool for the job is Test Kitchen. Test Kitchen is an integration test harness tool for testing infrastructure code on isolated platforms. The great thing about this test harness is that it allows you to run your code on virtualization technologies and various cloud providers.
Here is the cloud testing strategy for developers. Each checkpoint will execute static code analysis, unit tests for application and chef role cookbooks, server spec tests, and PhantomJS tests.
Local Development
Testing the application code locally using Chef, Vagrant, and VirtualBox
GitHub Pre-commit Hooks
Testing the application code every time a pull request is created by using Chef, Vagrant, and VirtualBox
Continuous Integration
Testing the application after merging a pull request into the master branch and deploying the application on a cloud provider (staging and production)
The growth of cloud solutions doesn’t change the importance of testing practices. It does, however, elevate the importance of testing early in a local development environment and will increase confidence in code changes before pushing code. Please—Consider implementing these test checkpoints above when developing your cloud testing strategy.
Command-Line Testing Suite Using PhantomJS
The headless test runner allows us to make assertions about the final state of the machine after the Chef Role Cookbook completes. It is important and required to start with a “clean” virtual or cloud environment to run your PhantomJS tests to get accurate results. (Here is an example of PhantomJS Chef Role Cookbook developed by Custom Ink.)
Just remember that PhantomJS testing is not a shortcut for Selenium functional testing. PhantomJS is a perfect lightweight test runner to evaluate a web application before launching your Selenium tests across multiple browsers and platforms on Sauce Labs. What is the makeup of the lightweight command-line testing suite?
Let’s outline the lightweight acceptance test suite for checking a deployed application:
Compute the loading speed of a web application.
Capture network traffic in HTTP Archive format (HAR) format file. (The HAR is a JSON-formatted archive file format for logging of a web browser’s interaction with a site.)
Send HTTP GET and POST requests and validate the response such as the HTTP status code.
Set the initial viewport size before loading the page by choosing between ‘landscape’ and ‘portrait’.
The file system module allows access to files and directories, but I recommend using server spec testing for this type of validation.
DOM manipulation, pure interaction with the deployed web application by using the standard DOM scripting and CSS selectors. Keeps command-line tests super light.
Capture Screenshots
…
It validates that the build and deployment of your web application are ready for the next testing checkpoint.
Conclusion
I hope this blog post has encouraged you to look into PhantomJS and start defining a cloud testing strategy for your cloud applications. The idea behind cloud testing is that it is easier and cheaper to catch and troubleshoot issues locally, as opposed to having staging or production blow up. The tooling solutions are available. What is stopping you from changing your cloud testing strategy? Nothing.
To close, PhantomJS comes with a lot of included examples. I recommend looking them over.
Greg Sypolt (@gregsypolt) is a Senior Engineer at Gannett – USA Today Network and co-founder of Quality Element. He is a passionate automation engineer seeking to optimize software development quality, while coaching team members on how to write great automation scripts and helping the testing community become better testers. Greg has spent most of his career working on software quality—concentrating on web browsers, APIs, and mobile. For the past five years, he has focused on the creation and deployment of automated test strategies, frameworks, tools and platforms.
