Testing Vue.js components is different from testing regular JavaScript modules or classes in two ways. First of all Vue.js components depend on Vue.js, its global state and oftentimes on plugins like Vuex or the vue-router. Second, Vue.js single file components usually are compiled with webpack, the regular workflow of using Babel to compile JavaScript code before testing it, is not sufficient in this case. Let's find out how to deal with those challenges...
Today, in the third and final part of this series about acceptance testing with Nightwatch.js and Cucumber.js, we will integrate automated cross-browser testing powered by BrowserStack into our workflow...
In an ideal world, it should be possible to write basic acceptance test specifications without having to add any new step definitions. In the real world this is not always possible, because some features, with some very specific functionality, might need special treatment and are impossible to test without writing custom step definitions...
Nightwatch.js is battle-tested and has proven to be a potent tool in the utility belt when it comes to conducting end-to-end tests. The combination of Nightwatch.js and Cucumber.js enables the writing of robust automated acceptance tests in plain language (Gherkin) so that every project stakeholder can read and understand the test definitions...
Today we will create a progressive web app (PWA) based on Vue.js with Vue Router, featuring code splitting with webpack. Luckily, building progressive web apps has never been easier. Thanks to the hard work of many wonderful people in the open source community, every major JavaScript framework comes with an effortless way of kickstarting a new PWA powered project via a simple CLI command...
Today we're going to look at the approach of using CSS selector namespaces to help us with detecting changes which have to be considered in the tests. Using separate selectors for testing also leads to a more stable way of structuring our code without tightly coupling our tests with the markup and CSS styles of the implementation...
Yesterday I learned a valuable lesson on how to solve a problem by looking at it from a different angle. The longest open issues in the node-sass-magic-importer GitHub issue queue, is about source map support...
Today we're going to implement taxes and discounts into our Payment Request API powered checkout process. The code is based on the code we've produced in the previous steps...
The first article of this three-part series was about building a very basic checkout process using the Payment Request API. In this article we're going to build a basic shopping cart implementation followed by a Payment Request API powered checkout process...
Thanks to the Payment Request API, accepting payments from your users now is a piece of cake. Albeit support from third party payment processors is still rather limited – Android Pay being one of the most notable – this will very likely change in the near future. Furthermore you don't necessarily need a third party payment provider to integrate directly into the Request Payment API, it is also possible to collect credit card data from the user via the Request Payment API and send them to your payment provider using it's own API...