I Pushed my Code to the Master Branch Without Tests

Hold up! I got a confession to make.

I pushed my code to the master branch without tests.

Until I stumbled upon TDD, I had never really understood the purpose or relevance of tests. I remember writing a whole project without tests and publishing it.

Can you believe it? Was I out of my mind blind?

Thinking about this still gives me heartache. Did the project work? Of course, it did. Until it didn't and I had to spend 3 whole weeks staring into the screen wondering what on earth had gone wrong. I mean, I just added a mini-feature, it should work! Sound familiar?

This could be us ... but we are writing tests now

We are going to split this up into the fundamental building blocks of all tests, which are; Tests must fail, tests must pass, and the code must be refactored. Let's dive in, shall we?

First of all, we have outlined the pain that comes from not testing, but not really as to the importance of testing in itself. For a view of this, we would summarize into the below off-the-batt pointers.

Giving the developer an understanding of the project requirements from the client's point of view.

In this sense, a developer who writes tests following the principles outlined earlier in this piece is made to think in terms of the project requirements earlier on. Which in short says; programming is more thinking than coding. Once you visualize what you want to achieve before doing it, it significantly reduces the chances of veering off the project in itself. You know this part of the page should display what, where this data comes from and expected results should the fetch not happen. You get the project's aerial view; writing, in the end, smaller modular code.

The confidence in shipping without fear of breaking other features of your code.

Small project? Sure, fine. Can this scale? How certain are you? What about that last little piece the project manager requested? Will it mean my service or call or method will not work? What about when the project grows larger and we change something? Will we go page by page checking whether each part still works and shows the expected message? Do we have this time?

Shorter feedback loop.

Shorten the x y and x pieces need w z k feedback loops. When you can tell directly from the onset that this piece of code will not work as it is given how the backend team has refactored the API, you shorten the time it takes for the QA team to notice it, the time it gets to get to you and the time it takes to figure out where in the code you need to fix. You have, at this point, already identified it.

These, are some of the reasons we write tests.

So what are some of the ways we can use to get this done? Where do we get started here? Glad you asked.

To kick us off, we highlight the tools and options.

PS: We are not installing the internet of node_modules in our project, you can breathe.

Jest

Created by Facebook, Jest is an out-of-the-box package that comes bundled with assertion. Plainly, it shows not only that the test fails, but also where it failed; whether variable Y was not equal to X, and so forth. This is necessary more so when you find a test comparing, for instance, an arithmetic sum 5 to a test data of 5, failing, only later to realize that you passed the string '5' instead of an integer.

Mocha

As an elder brother to its counterpart, Mocha works just the same way, but with a little bit more configuration. To be precise, you have to include an assertion library separately. Most commonly used as a partner her, would be Chai.

Whichever of the two most used packages you use is up to preference. It all depends on how customizable your tests need to be and or what you are more comfortable with.

The two mentioned are global across javascript frameworks. What about the specific framework of choice here in our case (Vuejs)? We could say, we have libraries that make it much easier to test in Vuejs. Specifically, we are talking about Vue test utils, which is the official unit testing utility library for Vue.js and the Vue testing library, an abstraction of the previous.

So, first, we decide whether we want to use Mocha + Chai or jest, then we go ahead with what works for us between Vue test utils and the vue testing library or perhaps both.

To engrave this knowledge on testing, we intend to build a simple web application; a ToDo list. With this, we can track items, check them off as done, see what was done, edit items, delete these items, and so forth. Along the way, we use different approaches of testing and ping what one approach has to offer vs the other. Every step of the way will be guided by a systematic approach, to give a clear outline of the intent beforehand. So pause here, for a while at least, as we get our tools ready for the next section of this series.