Forem: Facundo Flores

Let's finally release it... with tests

Facundo Flores — Wed, 18 Dec 2019 12:15:28 +0000

Introduction

Every developer has been in that stage where he/she was pushed to just release the "new cool feature" for the product that is going to maximize the revenue for the company. Most of the times, arguments like: "the feature is working great, we did some manual tests", "you can always iterate", "it does not need to be perfect" and some other good ones come to the engineers and makes them wonder if shipping the code without unit, functional or e2e tests is ok. Well, if you would have started doing TDD instead, you were not be asking yourself that question.

TDD is hard... I spent too much time on it

Do you want to recognize how professional a software engineer is? Take a look over those PRs created by him/her self, can you see any tests? how much coverage is being added? does he/she complain about the value of writing tests?

If you are building a new feature, not writing tests is not an option, it is a must. That's a maturity sign. Even when you need to ship that feature as soon as possible or it is just a PoC (you can't count how many times those PoCs ended up in production).

But there are a few times when you are new to the codebase and you are asked to start building things on top. We have all been there, I know that feeling. You go to that page: thousands of lines with no sense, full of legacy code, no docs and of course no tests at all.

In that case, adding unit tests before doing anything, might be a challenge (of course you don't want to test implementation details, right?)
You may say: "ah! gotcha! where is your TDD now?"

Well, adding unit tests are not mandatory under those circumstances, writing functional tests could save your life! Detecting what needs to be covered becomes simpler, and of course, you can ask for help to people who have been there for a while: product owners, senior engineers, QAs, even the CEO!. This is your opportunity to add a lot of value: tests and docs. After finishing with your functional tests, you will be able to dive into the code and start refactoring the whole thing, and meanwhile, you could potentially find some opportunities to add unit tests.

Believe me, once you start with TDD you won't ever find any more excuses to not write your tests. You may wonder why they are so important:

First of all, they allow you (or your future peers) to refactor the code you wrote.
They will guide you to write more maintainable code. Remember mocking is a code smell
They will force you to understand the feature first.
They help you to catch bugs easily.
They will cover your a**

Do I need 100% coverage?

You need 500%... and yet, it is not enough.

Remember it is not about matching a metric. If it were for that, you can just do snapshot testing for all your projects and 'et voilá' ask for a raise or promotion.

Testing is all about making sure the value you are shipping to your users is the right one. Even when your code breaks on production, you don't have to worry about that, we are all human beings, just go to the code and reproduce the bug with a test (now you can ask for a promotion ;-)).

Tools for code coverage will help you to find those "spots" which may have a lack of tests and not covering them it is a sign of irresponsibility. If you don't need "that part of the code" / feature, then... just remove it, why do you want to have that in the code? KISS.

Do I only need integration tests?

Integration tests are more focused on the user's features. Let's say you want to write a calculator to solve linear equations. You will have some specs for:

Solve linear equation a * x + b = 0 You may say well, I can have some tests for them:

describe('calculator')
  it('should solve linear equation a * x + b = 0 with a <> 0')
  it('should solve linear equation a * x + b = 0 with a = 0 and b = 0')
  it('should solve linear equation a * x + b = 0 with a = 0 and b <> 0')

the code would be something like:

add(a,b) return a + b
subtract(a,b) return a - b
multiply(a,b) return a * b
solve(a, b, c):
  if a <> 0 return divide(multiply(-1, b), a)
  if a = 0 
     if b = 0 return "identity equation"
     if b <> 0 return "no solution"

now, you manage to pass your 3 tests and temptation will come to say: "let's ship it!" well... no.

How do you actually now that add subtract and multiply work correctly? How do you ensure that future developers will understand how those functions need to behave? For example, there is a change from the requirements and you need to implement multiply with recursive Karatsuba algorithm for large numbers, are you 100% sure you are not going to break anything else? (I won't ever be).

If you take a look, we have only 3 tests from those specs. Are you sure you covered all edge cases? Just... think about domain numbers... Integration tests won't save you from domain edge cases. Why would you add the following test?

describe('calculator')
  it('should solve linear equation a * x + b = 0 with a<>0 and a is a real number greater than 0)

that test does not belong to the calculator integration test feature, why don't you just add your checks to the multiply function? And if somebody tells you, you don't have to cover multiply because it is one line function... just write the test for the sake of god and show your professionalism.

But my manager told me there is no time for tests

Show your manager the following video

Probably you are in the wrong place. Or maybe this is your chance to drive a change and "make an impact".

Believe me, those who are complaining about you spend so much time writing tests, are the first ones that will come to you and ask: "why in the name of god you shipped a bug"... but this is a different story.

As you may know now, writing tests is not about satisfying QA people, or to prove to other people your code works, or to show how many new lines you covered, or how many commits you can show on GitHub to get a promotion. Tests are here to help you and guide through refactoring, to tell you and your peers "don't be afraid of touching this code". Tests mean empathy.

Remember that: "is not about how many features you ship, but rather about shipping the right ones".

Creational Patterns in JS

Facundo Flores — Thu, 21 Mar 2019 20:21:50 +0000

Constructor pattern

It is a bit different from other languages because we are not going to use classes for this (although they are available from ES6). So the main goal here is to create a new object with their own object scope. We are going to start taking a look at what the new operator is doing for us

If you put this operator in front of an object (remember functions are objects in javascript) it will give us a new object.
Link the created object to an object prototype (it is not inheritance btw)
Binds this keyword to the scope of the new object
Returns the previous this

(for more information you can visit new operator)

An example:

function Todo(title, isDone) {
    this.title = title;
    this.isDone = isDone;
    // here should be placed this, but new is doing this for us
}

So this pattern allows us to pass some parameters to a function (which is the name of our object), and because we are going to use new, this is available in our scope.

Let's take a look at how to use the constructor

// wrong way
a = Todo('title', false) // a will be undefined
console.log(a.title) // because a is undefined you can't access to a

// right way
a = new Todo('title', false) // a will be the object with this in context
console.log(a.title) // will print title

Factory pattern

It is one of the core patterns which allows it to create objects for you. The main purpose of this one is to hide the logic about object creation for some clients.

So, let's say that now we have personal and work Todos, and the difference is personal ones are done or not, and work ones can measure the progress.

function PersonalTodo(config) {
    this.title = config.title;
    this.isDone = config.isDone;
    this.complete = function () {
        this.isDone = true;
    }
    this.reset = function () {
        this.isDone = false;
    }
}

function WorkTodo(config) {
    this.title = config.title;
    this.progress = 0;
    this.addProgress = function() {
        if(this.progress > 90) return;
        this.progress += 10;
    }
    this.substractProgress = function() {
        if(this.progress < 10) return;
        this.progress -= 10;
    }
}

Now we can create our on TodoFactory

function TodoFactory() {
    this.createTodo = function(config) {
        if(config.type === 'personal') {
            this.todoType = PersonalTodo;
        }
        if(config.type === 'work') {
            this.todoType = WorkTodo;
        }
        return new this.todoType(config)
    }
}

Let's give it a try:

var myFactory = new TodoFactory();
var personal = myFactory.createTodo({type: 'personal', title: 'foo', isDone: false})

console.log(personal instanceof PersonalTodo); // true
console.log(personal) // personal todo with title: "foo" isDone: false

var work = myFactory.createTodo({type: 'work', title: 'foo'})

console.log(work instanceof WorkTodo); // true
console.log(work) // work todo with title: "foo" progress: 0
work.addProgress()
console.log(work) // work todo with title: "foo" progress: 10

What we can see here is a way to hide object creation (using explicitly new) for bringing to life new objects.

Singleton pattern

The main goal is to have in our application only one instance of an object. From the pattern, you usually will have a method in your object called getInstance to get the singleton instance and here you will check if the instance exists or you need to create one if it does not.

var TodoSingleton = (function() {
    var instance;
    function init() {
        var instance = new WorkTodo({title: 'workTodo'});
        return instance;
    }
    return {
        getInstance: function () {
            if(!instance) {
                instance = init();
            }
            return instance;
        }
    }
})();

Now, let's give it a try:

work1 = TodoSingleton.getInstance() // here we create a new WorkTodo
work2 = TodoSingleton.getInstance() // here we use the previous instance

console.log(work1.progress) // 0
console.log(work2.progress) // 0

work1.addProgress()

console.log(work1.progress) // 10
console.log(work2.progress) // 10

This pattern is very useful when you have to lead with services in your application. Particularly, you don't want to have different instances of one of them running in your app. Also, sometimes you want to load a third party lib in your app, which you want to avoid loading it every time you want to use it.

Extra

<button id="status"> Get Status </button>

function PersonalTodo(config) {
    this.title = config.title;
    this.isDone = config.isDone;
    this.complete = function () {
        this.isDone = true;
    }
    this.reset = function () {
        this.isDone = false;
    }
    this.getStatus = function() {
        return this.isDone;
    }
}

var personal = new PersonalTodo({title: 'foo', isDone: false})
personal.getStatus() // false

var element = document.getElementById("status");
element.onclick = personal.getStatus; // does not work this is in context of dom
element.onclick = personal.getStatus.bind(personal); // now you bind this to the object

How can we avoid using bind?

// Solution 1
function PersonalTodo(config) {
    this.title = config.title;
    this.isDone = config.isDone;
    this.complete = function () {
        this.isDone = true;
    }
    this.reset = function () {
        this.isDone = false;
    }
    return {
      getStatus: function() {
          return alert(this.isDone);
      }
    }
}

var element = document.getElementById("status");
element.onclick = personal.getStatus; // not getStatus will be in the context of the object

NOTE: The previous sample can be replaced using an arrow function from ES6.

Conclusion:

Design patterns are very useful while developing. Having the power of recognizing them can speed up your coding and solving common problems. Another advantage I see and appreciate is the fact you can easily understand new codebases and potentially learn new technologies faster because all software engineers base their programs on this basic and powerful stuff.