DEV Community: Alberto Yanes

Unit, Integration and E2E tests

Alberto Yanes — Tue, 05 Jan 2021 19:51:36 +0000

Many of us have surely heard some of these terms in our life cycle as programmers. Our daily life consists of writing code, new functionalities, and requirements, launching to production, and waiting for good news that no problem happened with the new code. There are many ways to achieve that peace of mind that everything will work well, or at least, that what is not related to the new functionality will not be damaged, one of the most effective is to perform tests on our lines, files, and components that are important to the product.

Regardless of the testing method, pattern, or architecture you choose, the idea of doing it is to be sure that the code delivery is correct, sleep peacefully and have a certain degree of confidence that the PR that you merged 5 minutes ago will not generate possible bugs, or simply be sure of having analyzed all possible spaces/fronts where an error could be generated.

For example, let's look at the following feature request:

Our friend Carl, the Product Manager 👷, asks us to make a button that generates a certain action. It sounds easy, right? But what if you forgot to take the correct action or tomorrow a coworker accidentally changes the aesthetics and now instead of a button it looks like a giant unintelligible box? (Believe me, some of you will have gone through something similar for sure 😜)

This is what I mean by being sure of your code for the small, medium, and possibly long term.

For each test method, the examples will have as a reference this little module of SumCalculator made in React.

const sum = (a, b) => a + b;

const SumCalculator = () => {
  const handleSubmit = (e) => {
    e.preventDefault();
    const [foo, bar] = e.target.elements;
    const fooValue = parseInt(foo.value);
    const barValue = parseInt(bar.value);

    const result = sum(fooValue, barValue);
    alert(result);
  };

  return (
    <div>
      <h1>Calculator Sum Module</h1>
      <form onSubmit={handleSubmit}>
        <label htmlFor="fooInput">Foo</label>
        <input type="number" id="fooInput" />

        <label htmlFor="barInput">Bar</label>
        <input type="number" id="barInput" />

        <button>Submit</button>
      </form>
    </div>
  );
};

Unit Testing

One of the most classic techniques of our era is unit testing, the concept is quite simple and straightforward, the idea is to isolate the code as much as possible to be able to perform a unit test in a simple, fast, and efficient way.

What can unit tests be applied to? in theory, any piece of code could apply it, some class, function, line of code, component, you name it! But remember: the smaller the chunk of code, the better.

This form of testing is one of the most essential tools for any developer, generally, in whatever development life cycle we are in, we should consider unit testing. It brings us great advantages such as making sure to fragment our code as much as possible to facilitate the use of the technique, if it becomes complicated, we know that we will have to give some small adjustments to the code to be able to isolate it as much as possible.

test("render all elements", () => {
  render(<Calculator />);

  // check if all the elements are rendered
  expect(screen.getByText(/calculator sum module/i)).toBeInTheDocument();
  expect(screen.getByLabelText(/foo/i)).toBeInTheDocument();
  expect(screen.getByLabelText(/bar/i)).toBeInTheDocument();
  expect(screen.getByRole("button", { name: /submit/i })).toBeInTheDocument();
});

Integration Testing

One of my favorites and extremely important. This technique is responsible for joining and combining parts of our application that are part of a flow and making sure that the interaction of the parts of our component is correct, allowing us to perform at the time of developing the tests if the interactions with the different pieces are correct.

It is one of the perfect unit testings complements since this method allows us to test the entire flows of the application.

window.alert = jest.fn();

test("should render alert", () => {
  render(<Calculator />);

  // fill out the form
  fireEvent.change(screen.getByLabelText(/foo/i), {
    target: { value: 5 },
  });
  fireEvent.change(screen.getByLabelText(/bar/i), {
    target: { value: 5 },
  });

  // submit the form
  fireEvent.click(screen.getByRole("button", { name: /submit/i }));
  expect(window.alert).toHaveBeenCalledWith(10);
});

End to end testing

Finally, the idea is to test and imitate behaviors that a user would have using our application, interacting with all the possible functionalities from the beginning to the end.

By adding this testing layer to our application, we will make sure to cover possible human interactions that our application may have, preventing bugs due to it.

Be very careful to confuse end to end with integration. Something that I have seen is that we usually mix these two concepts, although the idea is to test application flows, we can easily differentiate one and the other in that, end to end they run in the browser, unlike integration.

// Here I'm using Cypress for e2e testing very friendly for JS developers
describe("...", () => {
  beforeEach(() => {
    cy.visit("/");
  });

  it("render all elements", () => {
    cy.findByText(/calculator sum module/i).should("exist");
    cy.findByLabelText(/foo/i).should("exist");
    cy.findByLabelText(/bar/i).should("exist");
    cy.findByRole("button", { name: /submit/i }).should("exist");
  });

  it("should render alert", () => {
    const stub = cy.stub();
    cy.on("window:alert", stub);

    cy.log("fill out the form");
    cy.findByLabelText(/foo/i).clear().type(5);
    cy.findByLabelText(/bar/i).clear().type(5);

    cy.log("submit the form");
    cy.findByRole("button", { name: /submit/i }).click();

    cy.log("alert should be called with 10");
    cy.on("window:alert", (txt) => {
      // Mocha assertions
      expect(txt).to.contains("10");
    });
  });
});

Finally, this image is very useful to get an idea of what are the considerations to have when we use each type of test:

The more you scale, the more expensive the maintenance and development of the tests will be, also, it will be slower since it requires greater requirements to be able to build them.

Conclusion

Regardless of the type of test we choose, or we want to combine them, the important thing is to have confidence and certainty that what we have done is safe and that it meets the requirements of said functionality.

Implementing any type of test provides us with great benefits to our project, it not only generates trust, but it also serves as a code documentation base, helps us identify possible bugs as we generate the code, and many other benefits.

What has been the type of test that has impacted you the most at work? Do you apply any methodology? How does your work team agree to contemplate this practice in the flow of the application? Leave us a comment!

Follow me on LinkedIn or Twitter to up-to-date with my publications 🚀.

Unit vs Integration vs E2E Tests

Alberto Yanes — Mon, 04 Jan 2021 13:04:56 +0000

For example, let's look at the following feature request:

This is what I mean by being sure of your code for the small, medium, and possibly long term.

For each test method, the examples will have as a reference this little module of SumCalculator made in React.

const sum = (a, b) => a + b;

const SumCalculator = () => {
  const handleSubmit = (e) => {
    e.preventDefault();
    const [foo, bar] = e.target.elements;
    const fooValue = parseInt(foo.value);
    const barValue = parseInt(bar.value);

    const result = sum(fooValue, barValue);
    alert(result);
  };

  return (
    <div>
      <h1>Calculator Sum Module</h1>
      <form onSubmit={handleSubmit}>
        <label htmlFor="fooInput">Foo</label>
        <input type="number" id="fooInput" />

        <label htmlFor="barInput">Bar</label>
        <input type="number" id="barInput" />

        <button>Submit</button>
      </form>
    </div>
  );
};

Unit Testing

test("render all elements", () => {
  render(<Calculator />);

  // check if all the elements are rendered
  expect(screen.getByText(/calculator sum module/i)).toBeInTheDocument();
  expect(screen.getByLabelText(/foo/i)).toBeInTheDocument();
  expect(screen.getByLabelText(/bar/i)).toBeInTheDocument();
  expect(screen.getByRole("button", { name: /submit/i })).toBeInTheDocument();
});

Integration Testing

It is one of the perfect unit testings complements since this method allows us to test the entire flows of the application.

window.alert = jest.fn();

test("should render alert", () => {
  render(<Calculator />);

  // fill out the form
  fireEvent.change(screen.getByLabelText(/foo/i), {
    target: { value: 5 },
  });
  fireEvent.change(screen.getByLabelText(/bar/i), {
    target: { value: 5 },
  });

  // submit the form
  fireEvent.click(screen.getByRole("button", { name: /submit/i }));
  expect(window.alert).toHaveBeenCalledWith(10);
});

End to end testing

Finally, the idea is to test and imitate behaviors that a user would have using our application, interacting with all the possible functionalities from the beginning to the end.

By adding this testing layer to our application, we will make sure to cover possible human interactions that our application may have, preventing bugs due to it.

// Here I'm using Cypress for e2e testing very friendly for JS developers
describe("...", () => {
  beforeEach(() => {
    cy.visit("/");
  });

  it("render all elements", () => {
    cy.findByText(/calculator sum module/i).should("exist");
    cy.findByLabelText(/foo/i).should("exist");
    cy.findByLabelText(/bar/i).should("exist");
    cy.findByRole("button", { name: /submit/i }).should("exist");
  });

  it("should render alert", () => {
    const stub = cy.stub();
    cy.on("window:alert", stub);

    cy.log("fill out the form");
    cy.findByLabelText(/foo/i).clear().type(5);
    cy.findByLabelText(/bar/i).clear().type(5);

    cy.log("submit the form");
    cy.findByRole("button", { name: /submit/i }).click();

    cy.log("alert should be called with 10");
    cy.on("window:alert", (txt) => {
      // Mocha assertions
      expect(txt).to.contains("10");
    });
  });
});

Finally, this image is very useful to get an idea of what are the considerations to have when we use each type of test:

The more you scale, the more expensive the maintenance and development of the tests will be, also, it will be slower since it requires greater requirements to be able to build them.

Conclusion

Follow me on LinkedIn or Twitter to up-to-date with my publications 🚀.

9 Best Practices for REST API Design

Alberto Yanes — Wed, 11 Nov 2020 15:53:50 +0000

On many occasions, we don’t value the importance of establishing a clean, understandable, and scalable architecture when developing a REST API (or attempting to have this pattern), but in the long run, this has a giant impact as the application grows.

Suppose that the time has come to expose the interface that we were developing to users, how sure are you that they understand the same thing that you try to transmit in your interface? Not only is the understanding of the users who consume the application relevant, but also that it is understandable for your team and future people who will come to work with the application. It is essential to establish from the beginning an architecture that everyone will respect.

These are several of the aspects that I consider of most importance to take into consideration:

1. Use HTTP methods to give your endpoints meaning

REST API encourages us to use an HTTP method for each of the application's CRUD actions. Among them, we have the following variety: GET, POST, PUT, DELETE, and PATCH. The name of the endpoint associated with the resource must be accompanied by the HTTP method related to the applied action.

- GET /get_cats
- POST /insert_cats
- PUT /modify_cats
- DELETE /delete_cats
+ GET /cats
+ POST /cats
+ PUT /cats
+ DELETE /cats

2. Status codes must be according to the result of our API.

One of the most important qualities of our application is that the return of our endpoints is related to the corresponding status code. This means that the moment our result is successful or unsuccessful, we can relate in a more descriptive way the message we want to convey.

For example, if we get a status 200, we can immediately know that our result is successful, otherwise, if we get a status 400, the result is failed.

It is important to know the existing status codes and know which case we need to apply each one of them, since it may happen (and it's very common) that the return message is incorrectly associated with some status code, which is extremely harmful for the application since it generates confusion for developers and consumer users of our REST API.

// Bad, we return status code 200 (Success)
// associated with an error object
{
    "status": 200,
    "error": {...}
}

// Good
{
    "status": 200,
    "data": [...]
}

3. Filter, sort, and pagination support

Many cases in any application that consumes our API, will want, in some way, to consume fewer resources from our service, either due to performance, a search system, the information is excessive, or as simple as showing something particular from our resources.

Filter, sort, and pagination, in addition to expanding the functionalities of our API, helps us reduce the consumption of resources on our server.

Let's imagine the case of an endpoint that returns millions of results, how would our server react? (He would surely cry and collapse 😜).

GET /cats?race=misumisu&age=1 -> Filtering, retrieve all the cats that have the following properties: race is misumisu and the age is 1.
GET /cats?limit=15&offset=0 -> Pagination, return 15 rows starting with the 0 row.
GET /cats?sort_by=name&order_by=asc -> Sort, return rows sorted by name in ascendant.

4. Plural endpoints

One of the daily discussions that I come across regarding various API developments is deciding whether to use singular or plural for the construction of endpoints. In short, we want to maintain a solid consistency in our application, and for this, my recommendation is to build the endpoints in plural.

Resources will not always have a single result, a table can have many results and even if it had only one, and we place it singular, we will not maintain consistency in the format of the name of our routes.

“Consistency is the key to success” 🔑

- GET /cat
- GET /cat/:id
+ GET /cats
+ GET /cats/:id

5. Name endpoints with the name of your resources

Speaking of consistency, if we know that a route is responsible for handling the actions on a resource, it is essential to name it with the name of the resource directly, so when a person consumes our API, they will understand which entities they are working on.

For example, if you are going to return cats, you are not going to call your endpoint /dogs 🐶.

6. Resource hierarchy

What if we want to access a closely linked entity that belongs to a resource?

To show this relationship we have two options:

Hierarchically append article in our author endpoint
Query string

Let's take the classic example of "author" and "articles".

GET /authors/betoyanes/articles/create_cat_memes
GET /articles?author=betoyanes&name=create_cat_memes

These ways are valid and I have seen them in many projects. Personally, I consider it cleaner to use a query string than expanding the current path. The more the application scales, we will surely have a greater hierarchy and in turn, the route will expand. Even so, it is according to the criteria of each person, so use the one you prefer the most!

7. Versioning

As we develop, it is inevitable to have a stable and definitive version of our API, without errors, and bulletproof. Let's imagine we deploy our API and several clients are starting to use it, what would happen at some point when you need to add or remove more data from a resource? Possibly you generate a bug on the external services that consume our interface. That is why it is essential to have a versioning mechanism for our application.

There are several ways, but I am a fan of the versioned URI, in which we will explicitly have the version of our route in our endpoint.

// URI versioning v[x] syntax
GET /v1/cats
GET /v2/dogs

8. Caching

One of the powerful tools that will enhance an API in speed and low resource consumption is caching, the idea is not to ask your database for the same request multiple times if it continues to have the same result. There are several services that can help us implement this system, among them, one of my favorites is Redis.

We have surely heard that implementing a cached functionality generally comes with costs, and this is not the exception. Let us ask the following questions, is the information dynamic or is it static? If it’s dynamic, how often does the information change?

🚨 It is important to be aware of having long periods of information in cache, this can cause false results of the API by keeping the information for a long time, it is recommended to have short periods of cache.

9. Documentation

One of our best weapons and most hated by many people is documentation. In this context, a documented API is essential so that our users who consume it can understand several important aspects of our interface, including accessibility, responses, requests, examples.

Accessibility: The location and access of the interface are one of the most important qualities, and we do not want to give a how_to_use.txt to customers. Exposing our documentation on the cloud where everyone can see it, is the most convenient thing we can do.
Responses and Requests: The information we provide has to contemplate all the possible results that any resource may produce and how to consume them.
Examples: It is very important to provide examples of how we can consume our interface, even if it is a bash script that we can execute in the console and get a response from it..

Conclusion

Remember that our API is the interface that we expose to consume our back end service, with this in mind, it is important to apply the best possible principles so that the people who consume and work on it, are to their liking.

Although we are developing a personal project, we need to try applying the best principles that we consider, so we can get practice for when we enter a development team or project 💪.

I hope this article has helped you and adds some principles to your collection of good practices for your REST API! Do you have any other principles to add? Let us know in the comments section! 💬

Follow me on LinkedIn or Twitter to up-to-date with my publications 🚀.

5 tools to keep up with tech

Alberto Yanes — Tue, 27 Oct 2020 19:15:48 +0000

In programming’s world, we could say it is essential and very important to keep up with the new information of our sector, in this way you manage to place yourself in the lead and face the various challenges that are presented to you in your day to day in an optimal way.

Refactor some portion of the code, add a new functionality in the application, choose a technological stack for a new project, upgrade a deprecated code from 5 years ago (Who has not had this beautiful task? 😛).

These are just a few examples of different situations that may arise for which you need to make the right decisions that fit the problem to be solved. How is it achieved? With knowledge, constantly updating yourself and being self-taught.

That is why I want to give you some incredible tools that have helped me over time, to be informed of what is happening around.

1. Daily DEV

https://daily.dev/

This beautiful tool allows you to centralize articles from various platforms (Medium, Hasnode, DEV, etc), in one place. It is an extension that you can integrate into Internet Explorer, FireFox or Chrome. Every time you open a tab, a series of quite interesting articles will appear that you have previously filtered according to your interests when installing the extension. What I love the most about it is the simple fact that when you open a tab you can browse any variety of articles, definitely is one of the tools that I use the most in my day to day, one of the cons I see is that you can get distracted easily, but we know that acquiring knowledge is not a sin 😏.

2. Git News

https://git.news/

Something essential for any developer is to be able to view the repositories that are in trend, here you can have that information, and even filter by language. Usually I like to review this tool weekly, 80% of the cases I am surprised by a library that I never heard of and it solves many problems for me or that can attach perfectly with the project needs that i’m working on.

3. Product Hunt

https://www.producthunt.com/

Surely many have heard about this tool. It allows you to visualize the technological products that are in trend. In fact, many of the tools that I have used, I got them from this application. You can also subscribe via email and be informed weekly of the news that appears.

4. Trending Insights or Surveys

https://insights.stackoverflow.com/survey/2020
https://www.tiobe.com/tiobe-index/
http://pypl.github.io/PYPL.html
https://trends.google.com/trends/

Although these tools do not fit with the day-to-day (For example, developer surveys such as StackOverflow are annual), it is of great importance to dedicate moments of the year to review these types of metrics (languages, libraries, salaries, topics, among others) and be surprised with the results.

5. Eventbrite

https://www.eventbrite.com/

Finally, nothing more nor less than a platform to discover events, webinars, conferences, meetups, and classes that you could attend virtually or in person. Subscribe to the topics that interest you and you will surely receive a conference or two that you find attractive.

Conclusion

One of the experiences that I have learned throughout the career and that has marked me the most, is that you never have to stay only with the knowledge that the project, university, training, etc. gives you.

Always do more research, take a look on new technologies, discover new releases that will come out in the future, and ask yourself if you can integrate some of these things into the project you are currently working on. I’m pretty sure that your team will be happy to hear about new stuff to implement in their daily workflow 😉.

Always remember:

Knowledge is power

Do you implement other tech tool to boost up your knowledge? Let us know in the comments section!

Thanks for reading my article! I hope you have found some of these tools useful and that you can integrate them into your routine. Soon I will be actively posting on various tech topics.

Follow me on LinkedIn or Twitter to up-to-date with my publications 🚀.