Test-Driven Development with Vue.js

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