The forthcoming testing methodology within the Quasar Framework

This article goes into detail about the Quasar team’s decision making process regarding the ways in which testing is being integrated into the Quasar Framework v1.0.

Vantage Points

From the standpoint of the users of the Quasar Framework, the perspective of core developers and even the lifecycles of everyone’s CI/CD pipelines, any globally appropriate testing approach is at best highly complex and at worst composed of a myriad conjunction of moving pieces.

Without even considering major release changes in Babel and Webpack, when you multiply this situation by the ease with which developers can extend these stock components to rapidly build a range of production-ready assets and mix in any one of a variety of backends or databases, the matrix of testing possibilities looks a little bit like this:

Its flexibility and range make Quasar unique in the tooling pantheon and it should be obvious why it is so important to enable test integration. To this end we have been working for the past several months preparing the new testing mode for Quasar by reaching out to our community, finding the pain points and actually building testing harnesses that work with it. (Spoiler: We love Jest and Cypress!)

This article describes from a bird’s eye view what we hope to accomplish. If you want to see the RFC’s and MVP description that go into much greater detail, please consider visiting these Github issues:

[RFC] Add --mode test to quasar-cli [RFC] Add test runners to project during quasar init [MVP]: Documentation as dynamic dev server



0. A general frustration with configuring SFC-type .vue files in Quasar unit-tests and explaining away the difficulty of parsing it by declaring it unimportant, a mere interface to the real code… 1. Lack of framework-native testing ability is an obvious barrier to entry for many professional development teams. 2. There would be little relative effort involved to get a smoke test up and running that informs developers when testing compatibility alerts have been triggered.


Having too many options can be confusing for new users. There must be at least one simple, easily installable, reactive visual interface for running units, diving into coverage, watching e2e, integrating with device targets and including seamlessly in CI pipelines. Simultaneously, there must be a robust CLI system that supports developer preferences for specific test-harnesses, edge cases, unique treatments, flavours of Javascript, special urgencies and opinionated quality control.


The core development team ships unit-test-compliant snapshots and runnable smoke tests for stock behaviour. All of these tests should be easily extendable by users of the Quasar Framework and serve as best practice guidelines. There should be a publicly available, audited collection of statistical data of the smoke tests.


The only additional unit tests that app-developers are responsible for are their own, as acquiring sensical coverage data from .vue files is notoriously challenging. If the users opt-in to sharing their anonymised testing data, then aggregated statistical analysis is an interesting canary from user-land and can offer the core-development team insight into pain points.


This describes the motivations behind our concept of the @quasar/testing module as a multipurpose tool that serves the needs of core developers as well as app-developers. When it lands, it will have been shipped with our unit tests, snapshots, e2e, smoke-tests and event-triggers. As it unfolds, it will include a “dynamic storybook” as a quasar app, which hosts a heads-up-display as an interface to all of the currently installed tests, their configs, documentation about their integration within quasar, links to official docs and finally the current status of the most recent tests run within your project. It will even serve, for example, your lcov coverage as html and embedd your cypress videos. Combine it with ngrok, and you can even let clients audit your tests from your development box…

The Preview

We plan to release a preview of @quasar/testing in the summer of 2018. In its preview condition, it will offer an opinionated kitchensink of pre-configured and rigged test-runners for post-init installation in your Quasar project:

After we have refined the install and integration process, we will slowly begin to roll out extensions to the module (that come with recipes to get you started). We plan to release it alongside Quasar 1.0.


I would personally like to thank Edward Yerburgh for writing the amazing book, Testing Vue Applications — it is a must read! (I am not just saying that because he gave me a copy, which is true — you really need this book!)

If you want to find out more about the Quasar-Framework, please stop by:

Quasar Framework

High performance, Material Design 2, full front end stack with Vuejs


Written by

Instigating Design

Quasar Framework

High performance, Material Design 2, full front end stack with Vuejs