This is the first post in a series which will dive into unit tests within the VueJS code base in order to gain a deeper understanding of how elements within the Vue ecosystem work.
Beyond alerting one to regressions in a code base, well-written unit tests read like simple sentences and help those working on a project to understand what individual features do. Unit tests can also serve as great templates for documentation if they are written well as they should describe what a feature does and how it reacts to different inputs.
The VueJS documentation is excellent, but recently I decided to dig even deeper and begin exploring the source code behind Vue! The first piece of the code base I visited was the tests directory. Most of you have surely heard of Test Driven Development (TDD). Well, in this series I would like to introduce you to Test Driven Learning (TDL). The idea is to begin reading through the unit tests of the framework or library you are using early in order to gain a deeper understanding of how individual features work. TDL also has a beneficial side-effect in that it will reinforce the benefits of writing unit tests in your own projects and reveal solid testing patterns.
‘v-show’ unit tests
In this first post in the series we will take a look at the
v-show directive. The unit tests in full can be found here, but we will be walking through them piece-by-piece below. Below is the beginning of the
v-show test spec. The first thing you’ll notice is just how easy it is to write unit tests with VueJS. Discussion of testing frameworks, test runners, and Vue-specific testing is beyond the scope of this series, but is something I plan on writing about in the future. The next thing you may notice is that these tests are nicely written and do indeed read as simple sentences:
Directive v-show should check show value is truthy.
Directive v-show should check show value is falsy.
Let’s dive into that first test now. A new Vue instance is set up with a simple template which contains
foo variable is set to
true within the
data property. The
expect line reveals what this directive does, it appears that it alters the
display property of the CSS style of the element which
v-show is an attribute of. When the variable tied to
v-show, in this case
foo, is truthy,
display is set to an empty string. Hmmm this doesn’t seem to actually tell us much. Let’s move on to the next test to see if we can learn a bit more.
The next test is very similar with two key differences:
foo is set to
false, and we expect
display to be “none” in this case. Now we’re getting somewhere! An element with a
v-show directive which evaluates to
false will be hidden from the UI by having its
display set to “none”. Nice! We have learned something important about
v-show beyond the fact that it hides an element, it does NOT actually remove said element from the DOM. This functionality belongs to another directive,
v-if, which we will analyze in a future post.
Clearly the variable tied to
v-show could change throughout the lifecycle of a component. So what happens as
v-show evaluates to different values? The next set of tests explain this in detail!
The beginning of this set of tests reveals what we may have expected: as
foo is toggled from
display toggles from an empty string to “none”. Below this you’ll learn which values are considered “truthy” and “falsy” by the
v-show directive. Namely: an empty object, empty array, string, or number other than 0 are “truthy” while 0,
undefined are falsy. Sweet! We are developing a solid understanding of
v-show at this point as well as an appreciation for thorough unit testing.
So we’ve seen that
display alternates between an empty string or “none” depending on the “truthiness” of the value
v-show evaluates to, but what if
display is set to something else on the element? The next set of tests reveal the answer!
display is set on the same element that contains
v-show it will be respected if the value tied to
v-show is “truthy”. An element with
display: block will retain this style as long as
foo is “truthy”. On the other hand,
display: none will be set for “falsy” values. These tests also reveal that the original
display setting is retained even as
v-show flips back-and-forth between “truthy” and “falsy” values.
There’s just one more small set of tests to take a look at. This test wraps the
v-show in a
v-if and toggles
v-if back-and-forth. The important point to understand, which we will dig into deeper in the
v-if specific post, is that when
v-if evaluates to a “falsy” value its containing element and all children are removed from the DOM. These tests simply reveal that
v-show behaves as expected even when wrapped within a
We now have a solid understanding of how
v-show works and should feel confident that we could utilize it in our own apps, and we have yet to even take a peek at the docs! With that said, let’s turn to the docs now to see what they reveal.
The v-show API docs section should make complete sense to us now that we have studied the unit tests:
As I mentioned earlier, the VueJS docs are excellent, but I would argue that reading through the unit tests behind
v-show taught us all that the docs reveal and more in just a couple minutes of reading! Also, as I mentioned, reading through the tests taught us how unit tests should be written and how thorough they should be. Writing similar tests for features within your own apps should become a priority for you and your team!
In the next post we take a deep-dive into
v-if through its unit tests!
If you enjoyed this post please hit the little 💚 below to let me know you’d like more of this material! Thanks! 🤓