“Nobody cares about tests in front-end” Really?!
How I used to see tests in front-end
Tests for me were something distant 6 years ago. I used to develop several pages working for agencies — the time was very short and things needed to go fast. I can’t even count the number of hot sites that I did. At that time, I used to see several articles about how to test my JavaScript code, but I confess that this theme never aroused interest in me. I had the mindset that doing things without tests were faster (just visiting browser and refresh to “check” the result).
Time was passing and I started to get some maturity in my career: more significant projects were coming, and the complexity was increasing. So, someday I tried to apply to another’s companies jobs and the “shocked time” started in my life. In 2013 many people were talking about AngularJS and the benefits of testing the code. Every company was asking me to send code assignments with tests. From that time on, I changed my mindset and started to understand that tests were more than “some asserts”. Thus, things started to make more sense.
Ok, I need to learn it!
If you’re starting in the world of programming, it is common to think that tests aren’t necessary or they are demanding. I had this mindset myself for many years. When I finally saw the necessity of testing my code I started to find how to do it, and it wasn’t so easy like it is nowadays. Today, when an I see an easy and straightforward setup like Jest offers, I start to think why many developers aren’t doing it. My first setup or “suite” of tests cost me one whole day to configure pre-processors. I was using Jasmine with Grunt and it wasn’t easy. It is common that some people give up at the setup level. I’m saying it because I almost did fall into it.
After a long and challenging setup, I finally got everything done \o/. “Ok, now I’ve got my tests suite, but, how will I test my code?”. Yes! Hard times isn’t over. I think the major difficulty in frontend to test your code is to differentiate: what are “public methods”, what I must test and some other questions that could appear. I started to test anything, any method, any “component”, any interface etc. I think it would be good for me to separate things and to know what is really necessary to guarantee in our tests that everything works fine.
But, what is the reason of test it? So simple, no?
After that initial setup I was ready to start to test my code. Yes, I was starting a new step in my life and the first question that I had was: “Look at this functions, it’s obvious that it will work, why I need to test anything here?”. Yep, man, you need test it! Not convinced yet? Ok, let me show you.
Let’s imagine that you’re working on a big project with many features, how do you guarantee that everything will work fine forever? It doesn’t matter if the feature subject is a help function, like:
function sumFunction(a, b) {
return a + b;
}sumFunction(1, 2);
It’s pretty much obvious that the result will be 3, but if this function get a new condition like:
function someFunction(a, b) {
if (a > b) {
return (a * b) + b;
}return a;
}someFunction(5, 10);
You know the final result — it’s in your mind, I think. However, if someone passes an array rather than a number as the first argument, what will happen? Depends on your goal! Tests will guarantee that every condition and behavior will work as expected. The Test Driven Development (TDD) mindset is very important at this point because you can start describing the behaviors and, afterwards, start coding that method itself. Seems easy, no?
Test Driven Development (TDD) is another wall that I encountered in my way. The beginning is really hard to be honest. Every programmer loves to code and implement logic fast and get the problem solved ASAP. Changing this mindset and starting things with tests rather than the logic implementation is extremely hard. We need to persist a lot to rethink this workstyle. It is necessary to put your mind to work and persist a lot to change it.
A big and complex project on my way
When I started to work with a product rather than only single sites, my conception started to change. Picture yourself: a bunch of teams working with a lot of features at the same time and nothing — or almost anything — can fail. How can you guarantee that everything will work together in perfect harmony for a long time? It’s complex but is the reality of many businesses that works with technology — specially in the SaaS environment.
My first major challenge at RDStation Marketing
Now it’s time to share some words telling you a personal history in Resultados Digitais. One of my first major challenges working here was to handle the Email Builder (named “Lego”) since it was made using EmberJS. Following the Ruby on Rails mindset, EmberJS encourages you to test everything: models, routes, components, controllers, etc. Always doing Unit Tests (methods and logics) and Integration Tests (specs evolving methods logics and it’s behavior in view layer). I confess that I had a great experience with it because, at the time, everything started to make sense and the benefits of tests happened to be more explicit.
The new workflow automation
I still didn’t told you about that “big and complex” project. After a long time working in Email Builder Team (Gorillaz), I was invited to work with another feature of my company, it was the new email workflow automation — a big and robust project involving VanillaJS (yes, no JavaScript frameworks), graph relations, drag n’ drops, events, components etc. We had a small deadline to launch it to production: something around 2 months and a lot of work to do.
First, a little context: the workflow automation is used to create different “routes” that a business prospect will go through depending on its actions (ex.: open an email, click in a email call to action, convert in a landing page form, etc). For Inbound Marketing, it really makes a lot of sense, since the lead actions will change steps until arriving at the bottom of funil. If you want to learn more about Inbound Marketing concepts, you can check here.
Backing to programming, the main goal was to conciliate the drag n’ drop events with our graph structure. If a user moves a step from 2 to 4, we need do some changes to persists behavior, something like that:
We created 3 basic functions that are responsible for: create, move and delete depending on actions made by the user when using a drag n’ drop feature (see example below). Independent of action, maintain the behavior made us spend a lot of hours drawing and burning neurons with complex logic, using just paper and pencils. At this point, tests started to make extreme sense, since we need to maintain all behaviors happening with a lot of actions and different scenarios.
That was just an overview of the challenge, but I expect that it shows you the importance of tests in a product life cycle — especially the complex ones. In a drop: “no tests, no delivery”. The final result of all that complex logic you can see below:
Conclusion
I think the main goal of this article is invite you to come out of your current scenario and think big and better! Probably, some time in your career you’ll work with a big and complex project that requires a lot of responsibility with short deadlines. Quality is the major mindset you need to have in your mind, your implementations need to work as expected to cover all the possible scenarios — preventing something like an incident (a major bug) in production.
Start to test today! It does not matter if your project has 1% of coverage, start with baby steps and go steady on your way. You’ve got a lot of technologies in your favor to decrease the tests setup time. There is no excuse not to start now, tests are an old practice and it’s an etic question not to implement it. If you need to know more about experiences described above, send me an email or call me on LinkedIn.
To finish, I invite you to watch a video serie produced by Fun Fun Function (click here) about tests.
A special thanks to LeoSL, João Paulo Barbosa, Henrich Moraes, Saimon Cruz, Fabricio Darosci Junior, and João Hornburg for their support.
Thank you! ;)
