What might seem obvious to some people could be weird to other. This is still the case for applying unit testing to JavaScript code in multiple browsers. In his blog post “Learning How to Set Up Automated, Cross-browser JavaScript Unit Testing”, Philip Walton provides a step-by-step approach process to create some automated testing of your JavaScript code.
Philip Walton thinks that even if there some JavaScript testing tools and frameworks, like Karma, that claim to make it easier to automated JavaScript tests, his experience is that these tools create often more complexity. The blog starts with a definition of automation as “using machines to off-load the repetitive parts of an existing workflow”. He makes very interesting and fundamental remark: “If you try to start with automation before fully understanding the manual process, it’s unlikely you’ll understand the automated process either.” The post continue with some examples of testing using Mocha. The problem in this simple approach is that when some of your tests are failing, there is no easy way to reproduce your bug and debug locally. It is also tedious and error prone to open different browsers to run your tests every time you change your code.
Philip Walton then describes a process that meet his requirements
* running the tests from the command line.
* debugging failed tests locally.
* running the tests on a CI machine
* being able to run all the tests automatically anytime somebody commits new changes or makes a pull request.
This process is based on the Saucelab platform, the ngrok access tool and the Easy Sauce Node package.
Read the complete blog post on https://philipwalton.com/articles/learning-how-to-set-up-automated-cross-browser-javascript-unit-testing/