What is a test?

A test is basically an automated mechanism to check if a function, feature or use case still works as it is expected over time and changes. Its implementation varies depending on the language and target. Simulating a user interaction in which several things must work together is not the same as checking if a function returns the same output every time it receives the same input.

This is how a test looks like in JavaScript:

function sum(a, b) {
  return a + b;
}

describe("when passing the same two numbers to the sum function", () => {
  it("should always return the same result", () => {
    expect(sum(1, 2)).toEqual(3);
    expect(sum(1, 2)).toEqual(3);
    expect(sum(2, 4)).toEqual(6);
    expect(sum(2, 4)).toEqual(6);
  });
});

Why should you start writing tests?

In essence, one of the main reasons is to add reliability to the project. The other one is to gain confidence when delivering your code. Furthermore, through tests, all the use cases are written and specified so that anyone can know what is that code for.

Maybe you are thinking that tests require more developing time. Or at least that’s what it looks like from the outside. The reality is that writing tests costs some extra time at the beginning, but it saves a lot of time. It avoids the majority of bug appearing (and the needed time to fix them) and automates the checking of every feature when changes are made (excluding the human factor as an extra point).

In other words, the time is spent preventing bugs from appearing and reappearing. In addition, think of the bad reputation that falls on the developing team when bugs occur more than once.

This can be avoided.

The reality of not testing

As a developer, you've probably been writing tons of functions that need to deal with lots of use cases. It’s easy and manageable when starting from scratch a new functionality due to the absence of legacy use cases. You are at the starting point. You develop the code needed to fulfill the current use cases and everything is ok, no fire anywhere.

As the application evolves, more use cases need to be controlled to have a consistent UX. Then is when you come back to the code and try to implement the new logic. If the code was written a few weeks ago, you probably can remember why it is written this exact way. Why there is an if-else statement returning different structures. Why it is apparently more complex than it should be, etc. But what if it was written a few months ago, or a year ago or, even worst, it was not written by you? Then the addition of these new use cases doesn't seem to be so smooth you thought it was going to be.

Don’t you think?

However you give your best to, first of all, collect the existing use cases and then implement the new ones satisfying them all. You reproduce, by hand, every case you think is important and check if everything is working fine. When you are done, you merge your code and then it is deployed to production. But now I ask you:

Have you ever really been confident deploying to production? Let me reformulate the question. Are you still completely afraid of deploying to production?

If you feel identified with the question, let me introduce you to the confident programming paradigm: TESTING.

The procedure

Of course not all use cases can be controlled. Furthermore, it is a waste of time (and, in the end, money) trying to cover them all. Having that into account, the philosophy should be:

1. Collect the stories, actions and use cases that the current feature is going to allow.
2. Write the tests.
3. Execute all the existing tests and ensure that they all pass.
4. Imagine only the realistic use cases that can cause bugs.
5. Write some extra tests.
6. Repeat step 3.
7. Deploy with confidence.
8. If a bug appears, control the specific use case in a test and repeat step 3.

That’s it. Cover the main use cases, only let the bugs be reported once and always execute all the tests when changes are made.

Congratulations!

You are now on the path to develop with confidence and deliver reliability.