DEV Community: Dang Quoc Khanh

Writing (unit) tests action, event in Moleculer with Jest

Dang Quoc Khanh — Wed, 15 Feb 2023 16:22:50 +0000

1. Preface ⛄

Moleculer is a powerful microservice framework for NodeJs. Because of designed by a microservice architect, we have more than one service responsible for its duty. In order to communicate with other nodes, we can configure transporter like TCP, NATS, Redis transporter, MQTT, AMQP, and Kafka,.. or customize them to be suitable for your business.

Beside design feature to interact with other node, we need to writing unitest for each feature, function inside to it. An aspect of it, we also need to write unitest for action call each other. In this post, I will present a few of my ways to write unitest in this case.

Note: Please reading about Broker, Transporter, Action, Events concept before reading this post.

2. Understand about action, event in Moleculer

In the real world, if each of us represents a service so the actions look like the request you need from the other. But we have two cases to request something. First, we request something from others and want the result. Second, we request from others and we do not need or care about their response.
I have two easy-to-understand examples of these concepts:

Bob goes to the market and tells to the cashier, "I want to buy an apple". the cashier checks their stock and sells it to Bob or tells him it's out of stock. Bob will get the response from the cashier. This is the mechanism of actions in moleculer.
Bob's garbage was full so he leave them in the trash can and he doesn't need to know when they take it out or how to process the rubbish. He just leaves it and goes back to his work. This is the mecahnism of events in moleculer framework.

3. How to test action, event

Let's join the main content. Different from testing on the monolithic architecture, each service can be located on a different server and called to another service via the transporter.

In the original document, the example already tests the event called by the action. Based on the moleculer testing document, I have the basic implement test action which calls another action with 3 steps:

Mock service broker.
Create two services (we can load/create/import or create a new service and set test action to this service).

Okay, let's take an overview of the code...

describe("Testing calling actions", () => {
    // Mock service broker
    let broker = new ServiceBroker({ logger: false });

    // set start and stop service 
    beforeAll(() => broker.start());
    afterAll(() => broker.stop());

    // create bob service
    broker.createService({
      name: "bob-service",
      actions: {
        goToMarket(ctx) {
          const buyAppleResponse = ctx.call("cashier-service.sellApple");
          return buyAppleResponse;
        }
      }
    })

    // create cashier service
    broker.createService({
      name: "cashier-service",
      actions: {
        sellApple(ctx) {
          const isAvailableApple = true;
          return isAvailableApple;
        }
      }
    })

    // process test
    describe("Test bob buy apple", () => {
      it("should calling to another action", async () => {
        const viewBobGoToMarket = await broker.call("bob-service.goToMarket");
        console.log(viewBobGoToMarket);
      })
    })
})

Logic:

First I want to mock a service broker to create an individual environment to run our test.
Next, I re-build two services corresponding to Bob and Cashier and also create action for each service.
Process call service via Service Broker to make sure it works.

You can imagine the communication above like this:

When we replace the actions called with the events, we will not have the response because we don't care about the result or whether the call event lose.

Another way to test an action is to get only the action that we need to test and mock all actions, events, calling to the database,.. inside this test action. The solution depends on your style, business logic, or use context.

4. Conclusion

Here is an unitest example when I'm trying to test action with mock action. It's similar when we replace action by event. I think it is simple and hope it easy to understand. I'm new bie in microservice and moleculer framwork, give me an comment if I have any shortcoming.

Follow me and give me your heart if you're interesting ❤️
Thanks for reading 😍

5. Reference

https://moleculer.services/docs/0.14/testing.html

Logging levels

Dang Quoc Khanh — Tue, 14 Feb 2023 15:10:03 +0000

Logging levels?

Log is a piece of information that was shown when the application runs through that code. Its information serves for troubleshooting and monitoring. It can be saved in a log file and supervised by any monitoring tool. When something happens with your application, I think the first thing you want to do is check the log to check what happens with your code. It's really important when we write logging in the right way and have enough information to serve that case.

Another case we can think about is that maybe in your sleep, the application caused some error for a specific case, it's a critical bug but not popular in our system. If you put in some logs in your code, the next morning will be very easy for you. Just check the log and find the reason why it happens.

Log Level Hierarchy

In most logging frameworks you will encounter some of the following log levels:
Severity affecting the system is arranged in order from top to bottom

Log type	Details
OFF	This log levels does not log anything. We will get no logging in our application
FATAL	This log usually use to show critical errors which can break down the server or the business logic is no longer working. A FATAL log level may be used when the system is not able to connect to a crucial data store like a database or payment system are not available or any executing function `breaks down` the system, `sys_error`,...
ERROR	The log level I'm using is very popular. This log is used when we `throw errors` in functions that we can catch or prevent at that time. This error can prevent one or more functionality next. Imagine that this log can use in your try-catch function and it affects the user experience.
WARN	The log level indicates that something `unexpected happened` in the application. The problems or issues that might disturb the process of the functionality. The application does not fail in this case. For example, passing the error occurred that the send notice function like webhook to partner.
INFO	The standard log level that `something happened`, the application entered to the specific state or just log to easily check again to make sure that steps working right. For example in this log, we can use the INFO of the request payment of the user, request authorization, and the result after calling from 3rd parties. Noted that the information in this log might not include the error.
DEBUG	The log usually use for developers to `debug` on the local / dev environment. It will be disabled in the production environment because it might be large. In specific cases, we also use this log on production. Less granular compared to the TRACE level but the developer use it every day. This log includes the information for `diagnosing issues` and `troubleshooting` or running on the test environment for the purpose of making sure everything is running correctly
TRACE	The most rarity case when we want to know what happening in your application and in side the third-party libraries that we use in our application. We can use this log to check the steps inside the algorithm in the library or you want to check what query calling to our database.
ALL	It is the combination of all other loggin levels. This log will log any logging levels that are defined.

Follow IBM documentations for logging levels, each level has an associated integer value usable by rules that monitor system mesages. View the detail values of each levels at IBM - Understanding logging levels

Logging levels format

We need to identify what is the suitable format for our system. I prefer some of these parameter in our log format (make sure it consistent in our application):

Timestamp: it will provide you with the order of the dozen of log (date or interger format).
Log levels name: look like INFO, ERROR, TRACE,... to make sure you can classify these log.
Message: the message you need to show. Make sure it use English language and friendly and it unique for each logs.

Example:

Do not write this code in our application if the outside does not have the try catch function:

try {
    // do something
} catch (err) {
    throw(err);
}

Conclusion

The log action is very important in our application. I don't want you to commit and push the code just to show the log because the error has been swallow.

Log can inform you not only how healthy your website is, but also how to calculate critical metrics like the error rate. Logs assist you in location the issue more quickly.