Testing Vue.js Applications

Edd Yerburgh

• Verlag: Manning
• Jahr: 2018
• ISBN:
  9781638356189
• Thema: Computer Science
• Thema: Programming in JavaScript

Summary Testing Vue.js Applications is a comprehensive guide to testing Vue components, methods, events, and output. Author Edd Yerburgh, creator of the Vue testing utility, explains the best testing practices in Vue along with an evergreen methodology that applies to any web dev process.Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications. About the Technology Web developers who use the Vue framework love its reliability, speed, small footprint, and versatility. Vue's component-based approach and use of DOM methods require you to adapt your app-testing practices. Learning Vue-specific testing tools and strategies will ensure your apps run like they should. About the Book With Testing Vue.js Applications, you'll discover effective testing methods for Vue applications. You'll enjoy author Edd Yerburgh's engaging style and fun real-world examples as you learn to use the Jest framework to run tests for a Hacker News application built with Vue, Vuex, and Vue Router. This comprehensive guide teaches the best testing practices in Vue along with an evergreen methodology that applies to any web dev process. What's inside

• Unit tests, snapshot tests, and end-to-end tests
• Writing unit tests for Vue components
• Writing tests for Vue mixins, Vuex, and Vue Router
• Advanced testing techniques, like mocking

About the Reader Written for Vue developers at any level. About the Author Edd Yerburgh is a JavaScript developer and Vue core team member. He's the main author of the Vue Test Utils library and is passionate about open source tooling for testing component-based applications. Table of Contents

• Introduction to testing Vue applications
• Creating your first test
• Testing rendered component output
• Testing component methods
• Testing events
• Understanding Vuex
• Testing Vuex
• Organizing tests with factory functions
• Understanding Vue Router
• Testing Vue Router
• Testing mixins and filters
• Writing snapshot tests
• Testing server-side rendering
• Writing end-to-end tests

• APPENDIXES
• A - Setting up your environment
• B - Running the production build
• C - Exercise answers

Chapter 1. Introduction to testing Vue applications

This chapter covers

• What testing is
• Why testing is useful
• The difference between unit tests, end-to-end tests, and snapshot tests
• Core Vue concepts

As a developer, you want to ship bug-free code. Nothing is worse than finding out on Monday morning that your Friday changes broke the live application! The only way you can make sure your application works correctly is by testing it, so it’s vital that you learn how to test applications thoroughly.

A good testing approach speeds up development, improves code quality, and limits the bugs in your app. A poor testing approach cripples a project. This book will teach you to test Vue applications effectively to make sure you get the benefits of testing and avoid the pitfalls. By the end of the book you will have become a Vue testing master, ready to test any Vue application you encounter.

To learn the techniques to test a Vue application, you’re going to write a test suite for a Hacker News clone from start to finish. The Hacker News application will use Vue, Vuex, Vue Router, and server-side rendering—just like most large Vue applications.

As well as teaching you the techniques, I want to teach you the mindset and approach to testing that I’ve developed over the years. Throughout the book I’ll give you advice to hone your testing skills.

This first chapter is a primer on testing Vue applications. I’ll give you a high-level overview of testing in general, the different types of tests you’ll learn in this book, and the Hacker News app you’ll write. Finally, I’ll explain some core Vue concepts, to make sure we’re speaking with the same vocabulary.

The first thing to do is to define testing.

1.1. Defining testing

Any academic paper worth its salt defines the concepts it uses before discussing them in depth. So, like a good academic, I’ll define what I mean by testing an application before I teach you about different testing techniques.

A simple definition is that testing an application is the process of checking that an application behaves correctly. It’s a no-brainer that you should verify your application behaves correctly, but the topic gets more interesting when you talk about the different testing techniques.

There are two main approaches to testing: manual testing and automated testing. Manual testing is where you check that an application works correctly by interacting with it yourself. Automated testing is the practice of writing programs to perform the checks for you.

Most of this book is about automated testing. But to understand the benefit of automated testing, you need to understand manual testing.

1.1.1. Manual testing

Every employable developer tests code manually. It’s the next logical step after writing source code, like how the next step after chewing food is to swallow it.

Imagine you’re creating a sign-up form. When you finish writing the code, you don’t just close your text editor and tell your boss that you’ve finished the form. No, you’ll open the browser, fill out the form, and make sure it completes the sign-up process correctly. In other words, you’ll test the code manually.

Manual testing works great for small projects. If you have a TODO list app that you can check manually in two minutes, you don’t need automated tests. But when your app grows to a certain size, relying on manual testing becomes a burden.

Let me tell you about the first large JavaScript application I worked on. The application was a mess. You’ve heard of spaghetti code? This code was spaghetti, tagliatelle, and linguini code rolled into one. It was very difficult to follow the application logic, and there weren’t any automated tests. Needless to say, the code had bugs. In an attempt to stop bugs, we would manually test the application before releasing it. Every Wednesday we would pour some coffee, open a list of user journeys to test, and hunch over our laptops for four hours to work through the set of instructions. It was painful.

Definition

A user journey is a list of steps that a user can take through an application. For example—open application, fill out form, click submit.

Considering we spent 10% of our development time manually testing the app, you would have thought we would stop any bugs reaching production. Nope. The application was riddled with them. The reason is that manually testing hundreds of features is difficult—it’s all too easy to lose concentration and forget to check something.

One time when working through a user journey, I accidentally forgot to check that clicking a button would display the metadata of a music track. The other developers must have forgotten to test that feature too, because the bug was live for months!

Although some of our manual testing time was spent testing new features, most was taken up testing old features to check they still worked. This kind of testing is known as regression testing. Regression tests are difficult tasks for us humans to do—they’re repetitive, they require a lot of attention, and there’s no creative input. Put simply, they’re boring. Luckily, computers are great at tasks like these, and that’s where automated testing comes in!

1.1.2. Automated testing

Automated testing is the process of using programs to check that your software works correctly. In other words, you write extra code to test your application code. After the test code is written, you can test your app as many times as you want with minimal effort.

You can use lots of different techniques to write automated tests. You can write programs to automate a browser, call functions in your source code directly, or compare screenshots of your rendered application. Each of the techniques has different benefits, but they all have something in common: they save you time over manual testing.

In the previous section, I spoke about an untested application I worked on. One of the problems with the application was that we had a four-hour manual testing process every time we wanted to release a new version of the app. Soon after I joined the team, the CTO decided that we should write automated tests to do this work for us. Over time, we reduced the testing time from four hours of manual work to 20 minutes of automated work.

After that experience, I’ve always written automated tests for large projects from the start. It’s easier to domesticate a horse that’s lived with humans from birth than it is to tame a wild horse in captivity. In this book you’ll learn to create a tame application by writing tests right from the application’s conception.

Automated tests are great for checking that your application still works. They also make it easier to review code changes to an application. Let’s take a look at a real-world example of using automated tests—testing pull requests on GitHub.

1.1.3. Testing pull requests on GitHub

GitHub is a website that hosts Git repositories. A lot of open source projects like Vue are hosted on GitHub, and most of the companies I’ve worked for keep their code in private GitHub repositories.

Definition

Git is a version-control system. I’m going to assume you’ve used it before and are familiar with the concepts of merging, branching, and committing. If you haven’t, check out the Git docs: https://git-scm.com.

Pull requests are part of the GitHub workflow. They give developers the chance to review code changes made on separate branches before they are merged into the master branch.

Note

if you aren’t familiar with the GitHub flow, read Understanding the GitHub Flow—https://guides.github.com/introduction/flow.

Without tests, when you review a pull request you need to pull code changes to your machine, run the app, and test the code manually to verify that it still works. This is time-consuming, and you won’t be surprised to hear some people skip this process entirely when they review pull requests.

Automated tests make this process much easier. When you have automated tests in a project, you can set up a service to download the pull request branch, run the test suite, and report back whether the tests passed or failed (figure 1.1). As long as you trust the tests, there’s no need to check the code on your own machine.

Figure 1.1. A pull request that passed the tests; the tick appears when the tests have passed.

Note

Most open source projects require developers to write new tests when they add new functionality. Vue accepts only pull requests that include tests for the new code.

As well as making pull requests easier to review, automated tests make modern workflows like continuous integration and continuous delivery possible. If you’re interested in these workflows, you can read about them on Martin Fowler’s blog (http://mng.bz/nxVK).

Now that I’ve defined automated testing and manual testing, it’s time to get more specific. The next section provides an overview of automated testing techniques, and how you can use them to check your applications.

...