Testing Your Application in Various Environments
Problem
You have a set of environments (operating system and browser) you need to support,
but you don’t have enough machines to test your application or library in each
environment.
Solution
Use an emulating tool or browser testing service that can test your application in all of
your environments. These aids help you not only test the integrity of the code, but the
appearance and behavior of your user interface.
EXPLAIN
In-house testing works if your customer uses a finite set of machines and you can easily
re-create the environments, or you work for a large enough corporation that can afford
to set up one of everything. For most other situations, you either need to use some form
of emulation tool or a service.
This is especially critical when you’re testing client-side JavaScript. Web or mobile de‐
velopment environments are undergoing rapid change, and a technology you think is
safe to use may end up blowing up in your face when you test the functionality in
environments other than the ones you use for development.
Emulators are a favorite for mobile developers.
Some are specific to a browser, such as
Ripple for Chrome. Others are standalone tools like Opera Mobile Classic Emulator,
shown in or the Android Emulator (part of the Android SDK).
A variation for testing mobile applications is a simulator, which simulates some of the
environment but doesn’t fully emulate it at the hardware level. An example of a simulator
is Apple’s iOS Simulator.
If you’re more interested in testing how the client interface works in different browsers
and different environments, then you’ll want to look for a cross-browser testing service
(BrowserStack or Sauce Labs), or an application like Ghostlab .
You might also consider automated testing services, where you create a
script that’s automatically run (Selenium is an example). The key is to look for a service
or tool that provides interactive testing—not one that is primarily used to check out the
design of the page in different environments.
One advantage to some of these tools is
they provide testing in both browser and mobile environments. The disadvantage is
cost: either a one-time cost for an application, or a monthly or annual fee for a service.
The only tool that didn’t have a price tag attached is IE NetRenderer, which allows you
to test your website in every variation of IE, from versions.
One of the services I have used is BrowserStack. It, like most of the other tools and
services, provides a trial period for testing the service. In addition, it also works with
testing environments, such as QUnit, demonstrated earlier in the chapter.
BrowserStack offers a variety of services, including screenshots of your site across sev‐
eral devices—desktop or mobile. From a client-side JavaScript developer’s perspective,
the service we’re most interested in is the Live testing, where we can pick an OS and a
browser and test our client application, directly. demonstrates running an
application in Safari on OS X—an environment I don’t have access to.
BrowserStack also provides automated cloud-testing of JavaScript applications. The
testing is free for open source software, and available for a fee for commercial and nonopen source testing. You can incorporate automated testing with various tools, such as
Yeti and TestSwarm. However, it’s primarily focused on testing Node.js applications.
No comments:
Post a Comment