A presentation at Vue.js Amsterdam in in Amsterdam, Netherlands by Sarah Dayan
Test-Driven Development with Vue.js Vue.js Amsterdam 2020
My name is Sarah, I’m a front-end engineer at Algolia, and I love Vue. I also love open-source, creating software for people, and using software from others.
I love that I can rely on what other people have made, and for them to be able rely on what I make.
Even if your code is dirty, not optimized, if you repeat yourself… it’s less of an issue than not having tests.
You can always refactor dirty code. Tests make that easier. It’s much harder to iterate on untested code.
Tests have one job: give you confidence that you aren’t shipping broken software.
That’s it. Tests are practical.
This isn’t about making your tech lead happy. You don’t get bonus points for writing more tests.
Yet, we often neglect tests.
I don’t know about you, but when I’m done writing a component, I have no idea where to start testing it.
What should I test? HTML structure? Should I call methods?
Should I go for 100% coverage? Should I write unit tests or e2e tests?
It’s complicated. So what often happens?
We procrastinate. We decide to do it later, and ship without tests.
Or we do it last minute and write incomplete tests. Or we go defensive and test everything.
With time, we test less, or with less precision.
Worst case, we never write them. By show of hands, who ever pushed untested code to production?
In all these situations, we never feel confident shipping new stuff. I don’t know about you, but I’m not a fan of spending my nights and week ends fixing issues that could have been caught by tests.
So, what can we do about it?
TDD was popularized by Kent Beck. You write tests before you write the code.
It forces you to think before you code, which leads to better, more robust code that behaves as expected.
It goes in 3 phases:
We start with writing a test, a specification of how the code should behave.
Then, we run it, and make sure it fails.
This step is crucial, because we need to ensure that our test CAN fail.
Then we make the test pass with the most stupid possible code.
We don’t care about pretty, performant, or even “right”.
We care about making the test pass. It’s all about ensuring the output.
Finally, we refactor the code to make it behave properly.
Time for performance, removing stubs, using better data structures.
But the goal here is to ensure that the test keeps on passing.
TDD and Vue work well together.
Instead of trying to guess what to test from finished code, you start from what the component should do, without caring about how. This way you only test the public API, without forgetting anything.
We want to build this file upload widget.
Coding time!
So our tested component is being reviewed, and we get an issue report:
“Hey, so I tested the component with smaller files, and there’s an issue.”
Hmm. Clearly, we have a problem. We’re always showing the file size in megabytes, while it would make more sense to go with a smaller unit when the raw value is smaller.
The value, per se, is correct, but we have a view logic error.
TDD is perfect for fixing issues.
When there’s a bug, we know what we want, we know we don’t have it, and we try to find how to get from what we have to what we want.
Back to coding time!
Testing scenarios depend on use case and expectations.
All you need to ask yourself is: do I care about this if it changes? Does anyone?
Test the stuff that shouldn’t change without you knowing, don’t only add tests for the sake of it.
TDD lets you write robust tests, not too many and not too few.
TDD helps you focus on exactly what to test, by defining, before writing code, if this is part of the contract or not.
One of the things I love with TDD is that it forces you to focus on the right things. Your software’s contract is infinitely more important than the way you implement it.
Implementation will change over time. It’s not that important. But a strong contract is.
If you’ve ever had to fix critical production bugs, you know it feels close to holding an open wound on a surgical patient with one hand, while trying to operate with the other one.
It’s messy, stressful, sub-optimal, and there are good chances you’re going to screw up something else in the process.
TDD can be scary if you’re used to faster development cycles. But it’s worth it, because not testing properly takes more time in the long run.
Tests help you catch bugs before they make it to production, and TDD helps you write better tests.
If you think you should test your software, then you should care about making these tests useful in the first place.
I encourage you to try. One good way to test it is to use it when you fix bugs.
You may discover a method that helps you ship better software, and feel more confident about hitting that “Deploy” button.
Thank you!
http://bit.ly/tdd-vuejs-amsterdam
Testing a component can be counter-intuitive. It requires a mental shift to wrap your head around the differences between testing components and testing plain scripts, knowing what to test, and understanding the line between unit and end-to-end tests.
TDD makes everything easier. Instead of writing tests by examining all bits and pieces of a finished project, and trying to guess what you should cover, you’re doing the opposite. You’re starting from actual specs, a list of things that the component should do, without caring about how it does it. This way, you’re ensuring that all you test is the public API of your component, but you’re also guaranteeing you don’t forget anything.
In this talk, we’ll cover why TDD is an ideal method for testing Vue components properly, and we’ll do it together live. We’ll deep dive into why TDD works the way it does, and how it can bring you full confidence over iterating on your Vue projects. At the end of the talk, you will know exactly what to test in your Vue components, and how to do it efficiently.
The following resources were mentioned during the presentation or are useful additional information.
Here’s what was said about this presentation on social media.
for free. You
can too.