DEV Community: Matheus Gonçalves da Silva

It's all about unit testing?

Matheus Gonçalves da Silva — Sat, 08 Feb 2025 21:29:29 +0000

It's a major subject with many controversial opinions from both sides. Although both are not wrong, one is a bit more redundant, in my opinion. Before we jump in, I'll leave this with a question: Are unit tests enough to prove our code is sound and correct, and prevent bugs? Let's discuss it.

We need to start with a base application, let's say a nestjs application, with vertical slice architecture, where our application is mainly composed by: controller, service and a repository.

Inside a repository, we will have data fetching, in most of the applications that's where you perform your database queries/selects/updates.

Inside the service layer, it's supposed to handle business logic, whereas in 98% of the time it's only used to pipe data from the repository back to the controller.

Inside the controller, well, it's only job is to receive the request and call the service layer.

With all the definitions out of the way, let's define what are the tests that we usually do:

Controllers

On controllers, our main concern is to know if the services are being called correctly, only that. So 110% of the time we are just piping data to the services, so we usually do:

describe("UserController", () => {
    let controller: UserController;
    let service: UserService;

    beforeEach(async () => {
        controller = await Test.createTestingModule({
            imports: [UserModule],
            providers: [{
                provide: UserService,
                useValue: {
                    findAll: jest.fn().mockResolvedValue([])
                }
            }]
        }).compile();

        service = module.get<UserService>(UserService);
        controller = module.get<UserController>(UserController);
    })

    describe("list users", () => {
        it("should return an array of users", async () => {
            service.findAll.mockResolvedValue([{
                userId: "1"
            }]);
            const result = await controller.listUsers();
            expect(result).toEqual([{
                userId: "1"
            }]);
        })
    })
})

The same pattern will be followed for all the methods on the controller, which does the same thing, expecting a result and seeing if we are receiving it.

Does it prove something? Does it prove if the business logic was implemented correctly? Are the joins and the table columns being well defined??

Totally not

There are so many nuances on a more complex application that these tests on the controller don't prove anything.

Services

Here is where we start to have the possibility to have more business logic into place, it's where we pull data from database and do something with it. 99% of you reading only pipes back to the controller on a simple CRUD, but in other situations you will do something with all the data

Well, here's an example:

describe("UserController", () => {
    let service: UserService;
    let repository: UserRepository;

    beforeEach(async () => {
        controller = await Test.createTestingModule({
            imports: [UserModule],
            providers: [
                UserService,
                {
                provide: UserRepository,
                useValue: {
                    findAll: jest.fn().mockResolvedValue([])
                }
            }]
        }).compile();

        service = module.get<UserService>(UserService);
        repository = module.get<UserRepository>(UserRepository);
    })

    describe("list users", () => {
        it("should return an array of users", async () => {
            repository.findAll.mockResolvedValue([{
                userId: "1"
            }, {
                userId: "2",
                deleted: true
            }]);

            const result = await service.listUsers();
            expect(result).toEqual([{
                userId: "1"
            }]);
        })
    })
})

This somewhat proves something, say that for example, for some weird reason, we are doing filtering over the deleted users on the service layer, which aims to be an example of a """"complex"""" logic. This at a certain level, proves that the logic done inside the service is correct. This makes a checkmark on preventing bugs and acting as guardrails for future refactors. But for the simplest use cases where it just pipes back data, that's totally a waste of time.

Repositories

Here is where the fun begins! What is a repository supposed to do? Well, retrieve data from the database.

So how would we test it?

describe("UserRepository", () => {
    let repository: UserRepository;

    beforeEach(async () => {
        const module = await Test.createTestingModule({
            providers: [
                UserRepository,
                {
                    provide: getRepositoryToken(User),
                    useValue: {
                        find: jest.fn().mockResolvedValue([])
                    }
                }
            ]
        }).compile();

        repository = module.get<UserRepository>(UserRepository);
    })

    describe("findAll", () => {
        it("should return an array of users", async () => {
            const mockUsers = [{
                userId: "1"
            }, {
                userId: "2",
                deleted: true
            }];

            const typeormRepo = module.get(getRepositoryToken(User));
            typeormRepo.find.mockResolvedValue(mockUsers);

            const result = await repository.findAll();
            expect(result).toEqual(mockUsers);
            expect(typeormRepo.find).toHaveBeenCalled();
        })
    })
})

With the help of our friend chat gpt, I generated an example using typeorm.

As you can see, we are mocking the database. Well, again, will this prevent bugs or prove anything that the implementation is wrong?

HELL NO

As we proved over here, in 100% of the use cases testing a repository, a controller and sometimes a service is a waste of time, because if it does not contain complex business logic, you would be only proving that the data that you mocked is being returned correctly.

What is the correct approach then?

I'm very in favor of unit tests when there's complex logic on certain parts of the code and those can be easily broken on any change. By doing that you help others in the future understand the behavior of those functions and also prevent from future problems if someone change anything.

For those more simpler projects where we are basically doing a CRUD, E2E tests with testcontainers is your friend.

With those e2e tests you will be able to act as a real consumer of your API for example:

Showcase validation errors when interacting with your API
Check for data being correctly inserted into your database
Check for return data from apis
Check for errors and other things.

Don't get me wrong, unit tests have their place to guarantee testing business logic or elements that have a lot of baked logic inside.

I hope to make the world of testing better <3

SST - a parte da infra que pode ser legal

Matheus Gonçalves da Silva — Sat, 18 Jan 2025 19:58:51 +0000

Hoje em dia cloud providers estão cada vez mais em alta e saber o minimo possivel sobre eles meio que passou a ser um requisito implicito, ou um que faz muita diferenca para se destacar hoje em dia. Irei abordar SST, uma ferramenta que trás abstracoes muito interessantes e faceis encima do AWS CDK, um tooling da aws que transforma codigo em templates cloudformation.

Cloudformation

Nao vou entrar muito nesse assunto, porém é muito importante saber o que é cloudformation: O AWS CloudFormation é um serviço que ajuda você a modelar e configurar seus recursos da AWS para despender menos tempo gerenciando esses recursos e mais tempo se concentrando em seus aplicativos executados AWS. Você cria um modelo que descreve todos os recursos da AWS desejados (como funções do Amazon EC2 e tabelas do Amazon RDS), e o CloudFormation cuida do provisionamento e da configuração desses recursos para você. Não é necessário criar e configurar individualmente os recursos da AWS e descobrir o que depende do que: o CloudFormation lida com tudo isso. Os cenários a seguir demonstram como o CloudFormation pode ajudar.

Porém é absolutamente contra intuitivo a maneira como os templates sao criados, sendo assim, abstracoes encima dele sao de suma importancia.

Comecando!

npx create-next-app@latest aws-nextjs
cd aws-nextjs

Iremos usar nextjs como exemplo para ilustrar o poder do sst e como ele interage com cdk/cloudformation por debaixo dos panos

Iniciar o sst:

npx sst@latest init

Após isso, sst irá gerar um arquivo de configuracao, onde podemos usar para nosso exemplo:

const bucket = new sst.aws.Bucket("MyBucket", {
  access: "public"
});

No código assim, após os templates do CF serem compilados, irá criar na aws um bucket chamado MyBucket onde estará exposto a internet, para acesso publico!

Agora, precisamos dizer para o deploy da nossa aplicacao next, que deverá usar esse bucket para colocar assets que nao necessitam estar pelo server:

new sst.aws.Nextjs("MyWeb", {
  link: [bucket]
})

Se formos para o codigo fonte, ele encapsula outras partes de infra para que nao precisemos lidar com isso

https://github.com/sst/sst/blob/9e099fe2caf4c093f8bc45d5b422a3b652a7dfe7/platform/src/components/aws/nextjs.ts#L7

Há mais coisas na documentacao do SST, mas quero apontar para um pedaco de codigo muito interessante: Lambda/Function

Para dar um pouco de contexto, lambda na aws é uma funcao que é executada, tem um comeco e um fim, podendo responder a eventos. Usando CDK há diversas maneiras de fazer o deploy da mesma, com SST, há algumas abstracoes novamente sobre ela:
https://github.com/sst/sst/blob/9e099fe2caf4c093f8bc45d5b422a3b652a7dfe7/platform/src/components/aws/function.ts

Há por exemplo, configuracao de node, versao, opcoes de bundler usando es-build (https://github.com/sst/sst/blob/9e099fe2caf4c093f8bc45d5b422a3b652a7dfe7/platform/src/components/aws/function.ts#L717-L720) entre outras coisas.

Tudo isso para no final das contas criar:

     return new lambda.Function(
            transformed[0],
            {
              ...transformed[1],
              ...(dev
                ? {
                  description: transformed[1].description
                    ? output(transformed[1].description).apply(
                      (v) => `${v.substring(0, 240)} (live)`,
                    )
                    : "live",
                  runtime: "provided.al2023",
                  architectures: ["x86_64"],
                }
                : {}),
            },
            transformed[2],
          );
        },

Por isso é muito mais simples usar as diversas abstracoes que SST nos disponibiliza!

We have been doomed by those best practices books

Matheus Gonçalves da Silva — Sat, 20 Jul 2024 21:30:24 +0000

we have been seeing a huge inflow of people in the industry that have read "clean coder architecture" or simply "clean code" and as first newbies consider that on their jobs daily we can also find seniors that have this as their bibles especially when reading through pull requests or creating new features without even knowing the history of those books and the point in history they have been written. This is a major flaw, we cannot take it for granted just because someone is a famous person or the book sells a lot every single day.

Let me explain a little bit. Clean code was released in 2009, with some core elements tracing back to early 2000s late 1990s. Why?

1995. Designing Object-Oriented C++ Applications Using the Booch Method. Prentice Hall. ISBN 978-0132038379.
2000. More C++ Gems. Cambridge University Press. ISBN 978-0521786188.
2002. Agile Software Development, Principles, Patterns, and Practices. Pearson. ISBN 978-0135974445.
2003. UML for Java Programmers. Prentice Hall. ISBN 978-0131428485.
2006. Agile Principles, Patterns, And Practices in C#. Pearson. ISBN 978-0131857254.

This was the history before clean code, a bunch of stuff on an era where code development was slow, the internet was barely at 10 MB in many houses and in many countries, information wasn't spread as fast as we know and we didn't have many of the toolsets that we have right now. CI/CD, great test tools, but nothing that would help decrease software development uncertainty, and neither tools that help us contribute to the development of anything (GIT). One may argue: but github was created in 2008, yep, but people that lived in the clean code era didn't have access to it yet.

Effective Peer Review in Development: A Guide

Matheus Gonçalves da Silva — Sat, 20 Jul 2024 01:30:37 +0000

Peer reviews are a cornerstone of quality software development. They ensure code reliability, foster team collaboration, and enhance overall project quality.

The Role of a Reviewer

As a reviewer, your primary responsibility is to ensure that the code meets the project's standards. This includes verifying correctness, performance, security, and maintainability. Additionally, peer reviews are an opportunity to mentor junior developers and share knowledge within the team.

Preparing for a Peer Review

Understand the Context

Before diving into the code, take a moment to understand the context of the changes. Review the associated issue or task to grasp the problem being solved. This helps in evaluating whether the solution aligns with the project requirements.

Conducting the Review

Code Quality and Style

Adherence to Standards: Check if the code follows the project's style guides and conventions.
Readability: Ensure the code is readable and understandable. Look for clear naming, logical structure, and appropriate comments.
Modularity: Verify that the code is modular and reusable where applicable.

Functionality and Correctness

Correctness: Confirm that the code works as intended and solves the problem it was designed to address.
Edge Cases: Consider edge cases and potential issues that might not be immediately obvious.
Testing: Ensure that the code includes adequate test coverage. Look for unit tests, and integration tests, and consider if any additional tests are necessary.

Performance and Security

Performance: Evaluate the performance implications of the changes. Look for any potential bottlenecks or inefficient code paths.
Security: Consider the security aspects of the changes. Look for vulnerabilities such as SQL injection, XSS, or other common security issues.

Feedback and Communication

Constructive Feedback: Provide feedback that is constructive and actionable. Focus on the code, not the developer.
Ask Questions: If something is unclear, ask questions rather than making assumptions.
Positive Reinforcement: Highlight what has been done well, not just what needs improvement.

After the Review

Approval or Request Changes

Approve: If the code meets all criteria, approve the changes.
Request Changes: If there are issues, request changes and provide clear guidance on what needs to be fixed.

Follow Up

Re-review: Be available to re-review the code after the developer addresses the feedback.
Continuous Improvement: Use insights from the review process to improve the review guidelines and practices over time.

Conclusion

Effective peer reviews are essential for maintaining high standards in software development. By following these guidelines, reviewers can ensure that code is of high quality, secure, and performant, while also fostering a collaborative and supportive team environment.

Happy reviewing!

Feel free to share your thoughts or experiences with peer reviews in the comments below. Let's continue to learn and grow together as a community!