Tag Archives: SauceLabs

PayPal hosts BayJax meetup dedicated to JavaScript testing


On November 20, 2013, the BayJax meetup group convened at PayPal HQ to talk about JavaScript testing. Four presenters, including myself, covered various facets of JavaScript testing. While the driving rain of that evening dampened attendance somewhat (there were a couple left over pizzas and some empty chairs), the high quality videos linked below can serve to widen the audience for this informative event.

Vojta Jina on Karma: Part 1 and Part 2

Vojta Jina discussed the Karma testing framework. In addition to running the exhaustive suite of tests for AngularJS, Karma is a standout JS unit testing framework in its own right. Enjoy:

Reid Burke on Testing Web Apps: Part 1Part 2 and Part 3

Setting up a continuous integration environment to run 100K+ tests on 12 different browsers is hard, but necessary. Managing the feedback from such a system is also hard, but necessary. Reid shares his valuable perspective based on meeting this challenge for the YUI team; using YetiSauceLabs, Jenkins and parallelization.

Santiago Suarez Ordoñez: Part 1 and Part 2

Santiago, a SauceLabs Senior Infrastructure Developer and Selenium committer, looks at the history of JavaScript testing and also towards its future. He discusses the origin of Selenium, Selenium2, how the Selenium2 API is becoming a W3C spec, and how the web driver codebase will then shrink to basically nothing. He also discusses what he sees as the ideal approach to automated testing for small teams. Finally he outlined a very cool cross-browser JavaScript testing API which SauceLabs is currently developing.

Matt Edelman on Nemo: Part 1Part 2 and Part 3

PayPal has adopted NodeJS for its web applications (please see krakenjs). We wanted to write our browser automation tests in JavaScript and execute them from within the application they are testing. While there were a couple different webdriver APIs available (selenium-webdriver and wd) in npm, there wasn’t an available framework which provided the flexible configuration needed to run the same tests across multiple environments and devices. I wrote the Nemo module to satisfy these requirements, as well as to suggest (not enforce) a factorization which promotes maintainable, readable, and reusable code.

As you can see in the diagram below, the system uses JSON wire protocol, which can communicate with numerous drivers (selenium grid, ghostdriverios-driverAppium, SauceLabs, etc.) in order to automate just about any browser or even native mobile applications:


We are using Nemo along with Grunt (see grunt task grunt-loop-mocha) and Mocha to write and run automated tests throughout the entire development lifecycle: development, QA, and continuous integration. Look for Nemo to be open source very soon!

One notable change since this talk occurred is that you can now parallelize Nemo tests in order to complete test suites more quickly.

Happy Testing!