DEV Community: João Pedro

Unit Tests in NodeJS

João Pedro — Mon, 14 Aug 2023 22:26:26 +0000

This will be a series of Unit Tests in X language (or runtime in this case haha). But for now we will stick with the unit tests and then, maybe, we can evolve into integration tests.

I want to start this series as a way of learning tests in some languages and analyze the different aproaches that every language gives to us to start in that important topic.

The application that we will be testing is a simple ideia that I had with free and open API's. Unit tests does not involve API's but I got the idea from one of these API's.

And why Unit testing does not involve API's?

I don't know, but I think that some people would disagree with me in this point. But in my opinion, Unit tests should just test the business rule of your app. And being an API is just part of your app that you deliver to the client, your application, for example, could answer smoke signals with a sensor, or it could receive messages from a PUB/SUB third party, there are millions of options. If you disagree, PLEASE, chat with me in the comments, I would love to talk to you, and I am not even joking, I really would love to understand why you think that way.

Continuing

Free API's I said. The idea came from free food API's being more specific this one. Awesome API here, take a look, maybe you have an idea for a cool project.

Our little project will be a function (that can be atached to anything, from API's to Workers, to recomendation Algorithms), I tried to build it in a very hexagonal way because testing really depends on your architecture, aside from testing you need a good arch that allow you to test without many work arounds (in portuguese we call "gambiarra").

export class GetRandomMealUseCase {
  private userFavorites = ["potatoes", "beef"];

  constructor(private mealSerice: IMealService) {}

  async execute(): Promise<
    [Error, { recipe: IMealRecipe; choiceLevel: RandomMealChoice }]
  > {
    try {
      const meal = await this.mealSerice.getRandomMeal();

      const howManyMealTheUserLikes = meal.ingredients.filter(({ name }) =>
        this.userFavorites.includes(name.toLocaleLowerCase())
      ).length;

      const result = { recipe: meal, choiceLevel: RandomMealChoice.Average };

      if (howManyMealTheUserLikes >= 2) {
        result.choiceLevel = RandomMealChoice.ReallyGood;
      } else if (howManyMealTheUserLikes == 1) {
        result.choiceLevel = RandomMealChoice.Good;
      }

      return [null, result];
    } catch (error) {
      return [error as Error, null];
    }
  }
}

Basically this is our whole little project. We have a service which just make a HTTP request and some basic error handling, I have choose as a error treatment something like Either where in the first position of the tuple is the error and in the second the response. I added the variable userFavorites fixed in the code, but this could be a parameter for our execute method.

We have 4 tests that I see for this little file. 1 for each choiceLevel and 1 for the error. Let's see how we can make those tests.

Mocha and SinonJS. We will be using those two fantastic libs for our tests with NodeJS. Mocha for the test cases and SinonJS for our mockings.

Unit tests

I started creating a mock service so that I could inject it in the use case.

export const getRandomMealBaseReturn: IMealRecipe = {
  name: "Mock",
  ingredients: [{ name: "Mock", measure: "1" }],
  instructions: 'Mock'
}

export class MealServiceMock implements IMealService {
  async getRandomMeal(): Promise<IMealRecipe> {
    return getRandomMealBaseReturn;
  }
}

That is our mock of MealService. This is guy has a default return that we will mock in other tests so that it satisfies our asserts.

Our first test we just need this base implementation of the meal service to create it so look at it below

describe("GetRandomMeal service tests", () => {
  it("Should return a random meal sucessfuly with average meal choice", async () => {
    const useCase = new GetRandomMealUseCase(new MealServiceMock());

    const result = await useCase.execute();

    assert.strictEqual(result[0], null);
    assert.strictEqual(result[1].choiceLevel, RandomMealChoice.Average);
  });
}

This first test has just the ideia of returning a meal with average choice and no errors, our next 3 tests will be just mocking the response so that we can test the other branches of the GetRandomMealUseCase and the error handling.

And that is it! Check the project over here. Like I said this will be a series of articles with this same project so, keep an eye here and study tests in other langs with me :)

Thank you!

Query Execution Plan inside SQL Server

João Pedro — Fri, 04 Aug 2023 01:03:14 +0000

Performance is a huge topic when dealing with databases, but for each case you will need a different approach for your data. And as always it is good to understand how the things work under the hood. Today we will be talking about Query Execution Plan inside a SQL Server instance

Disclaimer: This is not an advanced tutorial. We will cover just the basics over here

As we know SQL is present in our lives maybe even since our birth depending on when you have born. In my case I was born close to the 2000's so I am definitely in one of my governments SQL databases since then. And sometimes it is good to understand how the things work, I say sometimes but you usually need that when you are trying to improve something, and so that you can improve it you need to understand it.

A simple SELECT

Inside this article over here from Microsoft, they describe: Process a SELECT statement

In this section we can see clearly the steps behind one SQL statement execution.

The basic steps that SQL Server uses to process a single SELECT statement include the following:

The parser scans the SELECT statement and breaks it into logical units such as keywords, expressions, operators, and identifiers.

A query tree, sometimes referred to as a sequence tree, is built describing the logical steps needed to transform the source data into the format required by the result set.

The Query Optimizer analyzes different ways the source tables can be accessed. It then selects the series of steps that return the results fastest while using fewer resources. The query tree is updated to record this exact series of steps. The final, optimized version of the query tree is called the execution plan.

The relational engine starts executing the execution plan. As the steps that require data from the base tables are processed, the relational engine requests that the storage engine pass up data from the rowsets requested from the relational engine.

The relational engine processes the data returned from the storage engine into the format defined for the result set and returns the result set to the client.

Looking at this list we can see that the first two steps are just some manipulation so that the third step can happen. At the final of the third step we will have the execution plan.

The article above also describe a whole other world of details about everything that I am writing for you guys, so definitely check that out!

There are some interesting things about the plan that Microsoft describes in this article. They explain the general idea behind the the execution plan and give some interesting examples. Let's go through some facts about the execution plan:

It is chosen by its cost (That is measured by amount of computing resources)
It chooses the lowest estimated cost (In cases of thousands of execution plans it uses some complex algorithms to choose the best one without searching too much)
Tries to be the fastest as possible

A cool example with SQL Server 2022

I have these two tables over here:


CREATE Table tblAuthors
(
   Id int identity primary key,
   Author_name nvarchar(50),
   country nvarchar(50)
)
CREATE Table tblBooks
(
   Id int identity primary key,
   Auhthor_id int foreign key references tblAuthors(Id),
   Price int,
   Edition int
)

I just copied them from here

I inserted some data to both of the tables and executed the following query:

SELECT TOP(50) * FROM tblAuthors ta JOIN tblBooks tb ON tb.Auhthor_id = ta.Id

And boom I got the following execution plan:

And look how amazing these algorithms are, they have chosen to start from the join table, look at how many rows we have fetched from tblBooks and how many from tblAuthors. They have chosen this way due to the index available in that table, in this case we could just get 50 records from tblBooks and make a index scan in tblAuthors with those 50 records.

If you guys want to test an make your won execution plan download SQL Server Management Studio, unfortunately it is just avaiable for Windows. In linux over here I downloaded DBeaver Lite Edition, and unfortunately it is under license this version, but anyway, there is a lot of things that we can do with the DBeaver Comunity version too.

And why make all of these plans and stuff??

The Microsoft it self explains an example: In a construction, there are two companies responsible for building a house, each of them with the same blueprint, which one will be faster? The one that plans before it starts or the one that starts building without planning?

Cover Image from DCStudio