Six Questions with Edd Yerburgh, author of Testing Vue.js Applications

By Frances Lefkowitz

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. He’s currently working as a software engineer at the BBC in London.

Read more interviews from our Six Questions series.



Jump into any page of the book from the table of contents on liveBook!

Take 39% off Testing Vue.js Applications. Just enter intyerburgh into the discount code box at checkout at

By testing, are we talking about the test-driven approach to developing (TDD)? Or are you using tests in other ways?

In the book I follow a loose TDD approach, where I write the tests before adding the source code. Although I follow TDD, the techniques I teach are focused on testing in general—it doesn’t matter whether you write the test code before the source code, or the source code before the test code.


Is there anything about Vue.js that makes it particularly appropriate to a TDD approach?

Component-based front-end applications make testing easier than the unstructured jQuery applications that came before them, because components are natural units. But TDD doesn’t fit as well to front-end applications as it does to libraries or back-end applications that have a well-defined API.


Would it be possible to apply the tests and testing approaches you teach in your book to another language?

Yes, at a high-level, but the code is JavaScript specific. It could be useful to React developers or other JavaScript developers writing component-based applications. I wouldn’t recommend it to someone who doesn’t know JavaScript.


Tests are not silver bullets, right? When would we not want to use them?

Tests take time to write, time to maintain, and they make refactoring your architecture more costly. The benefit is that they can save you time from manually testing your app, but you need to decide if the benefit is worth the cost. I don’t test simple apps, and I rarely write tests for internal tools, because the benefit of catching bugs isn’t worth the cost of writing tests.

Front-end tests also have the problem that they can be brittle. They use browser APIs that require mocking, and sometimes the tests need to test the component output by relying on a DOM element’s attribute, which can change without breaking the functionality that’s being tested. This makes tests more expensive. So it’s a trade-off that you have to make as a developer. Generally I write tests for large apps with multiple developers working on them, because I find the cost of writing and maintaining the tests is outweighed by the benefit of having a good test suite.


You say you want to teach your mindset and approach to testing, as well as the techniques of testing. What is that mindset?

The testing mindset I teach is to approach testing in a way that couples your tests to your code as loosely as possible. You should be able to refactor the implementation of components completely without breaking unit tests.


I hear you accomplished quite a goal recently: reading 52 books in a year. What were some of your favorites?

I didn’t set out to read 52 books initially, but in March I noticed I had read more than a book a week since the beginning of the year. I like sci-fi, tech books, and non-fiction, so my favorite books were: Into Thin Air, Game Programming Patterns, and House of Suns. Into Thin Air is a first-hand account of an Everest attempt gone wrong. It’s informative, inspiring, and desperately sad. Game Programming Patterns explains patterns like byte code, the singleton pattern, and the prototype pattern with simple examples. The author has a good sense of humor, and I found it easy-to-read and informative. House of Suns is a standalone sci-fi epic about a universe inhabited by robots, post-human beings, and clones with infinitely long lifespans. The world-building in this book is phenomenal, and the story is gripping.