Test First Development With Vue.js, Quasar, and jest-cucumber

As a long-time backend/services developer, I have never had much patience for writing front-end applications in all the latest and myriad JavaScript frameworks. Angular is too complex, React is not intuitive, etc... About a year ago, a colleague of mine at Red Hat's Open Innovation Labs introduced me to VueJS and my front-end development attitude was forever changed. Vue is, in my humble opinion, the easiest and most intuitive front-end framework yet. Modular code, reusable components, and simple interactions are only a small list of the virtues of the framework. In this post, I will help you get started with a simple VueJS application and show you how you can develop applications in a "Test First" approach.

As suggested by the diagram above, 'Test First' means that we write a test before we write any code. You should create a test or tests which indicate your "finish line" for the work to be done before there is code which can make the test pass: We call this the "Red" state. We then write the MINIMUM amount of code possible to make that test pass: We call this the "Green" state. After the code review/pull request our team could have feedback or may have found issues which were not covered in our initial test criteria: We call this the "Refactor" state. In the refactor stage, we do not actually make changes, but we would likely create new user stories to cover that work and prioritize it in our backlog. It's easy to remember "Red, Green, Refactor".

In VueJS, we have several options for how we can approach testing, and in this article I will be somewhat prescriptive. We will use VueJS 3.x, Jest for unit testing, and Nightwatch with Nightwatch-API for End-2-End testing. The reasons for these choices will become clearer as we proceed.

Creating A VueJS Application Using Vue CLI

Let's start by creating a new VueJS application from scratch using the VueJS CLI. To install the CLI, follow the steps below:

I do not particularly care to write "basic" components which are common across many applications, so I tend to use Quasar Framework so that I get a nice palette of re-usable components which I do not have to maintain. It speeds up development, and if I run into a situation where I need to write I custom component I still can. So let's add Quasar to our project:

The End-2-End tests fail because the test was generated for a default VueJS application and now Quasar has replaced our components with their own configuration. This is not a serious issue as we need to write new tests from scratch anyhow. Let's look at how we might do that. First, we'll clean up some items left over from the basic Vue CLI project creation:

• Delete src/components/HelloWorld.vue
• Delete tests/unit/example.spec.js
• Delete tests/e2e/specs/test.js

Getting Ready To Write Specifications And Tests

Now that we have deleted the obsolete parts of our application, let's write a unit test for our landing page. Create the subdirectory tests/unit/features. Using your favorite editor, create a new file in that subdirectory called Home.feature. In that feature file, we will use the Gherkin language format to write our test specification. Reference material for jest-cucumber can be found HERE.

Now we have a feature specification with enough information for us to implement our test. We'll use these feature specifications in order to control our steps in our unit and E2E tests going forward. For now, we need to enable BDD testing in our jest.config.js file as follows:

Writing Our First Feature Specification

As mentioned above, features for BDD are often written using Gherkin. Gherkin is a nice intermediary format which is simple and expressive enough for non-technical people to read and write; but contains enough details for developers and testers to be able to create automated tests from. Let's have a look at our first feature file:

Once we have a feature file, we can then write our automated test using Jest, jest-cucumber, and vue-test-utils:

You might notice that each line item from our scenario detailed in the feature file is duplicated in our automated test code. This is how we tie the feature specification to implemented test code. Right now, when we run this code we should expect it to fail (and it does) because we have not yet written the code to implement the desired features.

All that's left is for us to implement the correct code in our Vue.js components/layouts/views in order to make the test pass:

In the code above, we have modified src/layouts/Default.vue so that the q-toolbar-title contains My New Application. That single change should be sufficient to satisfy out feature specifications. Let's run our tests again to see if it works:

SUCCESS!!

In the next blog post we will talk about how to implement feature specifications for End-2-End testing on Vue.js using nightwatch and nightwatch-api.