Forem: Fernando Andrade

Do commit ao deploy: CI/CD de uma API na AWS usando GitHub Actions, ECS e Terraform

Fernando Andrade — Thu, 12 Mar 2026 00:07:27 +0000

Sumário

Introdução
Pré-requisitos
Visão Geral da Arquitetura
Configurando o IAM para o Terraform
Infraestrutura como Código com Terraform
- Recursos Provisionados
- IAM Role para Tarefas ECS
- Task Definition (Fargate)
- ECS Service
- OIDC: Autenticação Sem Credenciais Estáticas
Dockerfile Multi-Stage
Pipeline de CI
Protegendo a Branch Main
Configurando as Secrets no GitHub
Pipeline de CD
Acessando a Aplicação após o Deploy
Segurança: OIDC em Detalhe
Fluxo Completo: Do Commit ao Deploy
Considerações Finais

Introdução

Colocar uma aplicação em produção vai muito além de escrever código. Envolve compilar, testar, empacotar e entregar de forma confiável e repetível. Neste artigo, vou mostrar como construir uma pipeline completa — do commit ao deploy — usando GitHub Actions para CI/CD, Terraform para infraestrutura como código e AWS (ECR, ECS Fargate) como plataforma de execução.

O conceito apresentado aqui é agnóstico de linguagem — funciona para qualquer stack que rode em um container Docker (Node.js, Go, Java, Python, etc.). Para os exemplos práticos, vamos utilizar .NET como referência, mas os workflows, a infraestrutura Terraform e o fluxo de deploy são os mesmos independente da tecnologia escolhida.

O objetivo é demonstrar como essas ferramentas se conectam para formar um fluxo automatizado onde um simples merge na branch main resulta em uma nova versão rodando em produção, sem intervenção manual.

Pré-requisitos

Antes de começar, você precisa ter as seguintes ferramentas instaladas e configuradas:

Ferramenta	Descrição	Link de instalação
Docker	Para construir e executar containers	docs.docker.com/get-docker
Terraform	Para provisionar infraestrutura como código	developer.hashicorp.com/terraform/install
AWS CLI	Para interagir com os serviços da AWS via terminal	docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html
Git	Para versionamento de código	git-scm.com/downloads
Conta AWS	Com permissões para criar recursos (IAM, ECS, ECR)	aws.amazon.com/free
Conta GitHub	Para hospedar o repositório e rodar os workflows	github.com

Nota: Para o exemplo deste artigo, também é necessário o .NET SDK instalado localmente para desenvolvimento. Se você estiver usando outra stack, substitua pelo SDK correspondente (Node.js, Go, JDK, etc.). Outro ponto é que a escolha em utilizar o ECS ao invés de um EKS ou EC2 é devido sua simplicidade na curva de aprendizado, baixo gerenciamento e que para fins de aprendizado os recursos mínimos definidos para esse laboratório não gerem altos gastos para o aprendizado.

Visão Geral da Arquitetura

O fluxo completo funciona assim:

Developer → Feature Branch → Pull Request → Validação (CI)
                                                  ↓
                                            Merge na main
                                                  ↓
                                         Build & Push (CD)
                                                  ↓
                                        Deploy no ECS Fargate

Configurando o IAM para o Terraform

Antes de rodar qualquer terraform apply, é necessário que o Terraform tenha permissões para criar recursos na AWS. Para isso, precisamos de um usuário IAM (ou role) com as permissões adequadas e configurar suas credenciais localmente.

Criando um usuário IAM para o Terraform

No console da AWS (IAM > Users), crie um usuário dedicado para o Terraform:

Acesse IAM > Users > Create User
Nomeie o usuário (ex: terraform-deployer)
Anexe as policies necessárias para os recursos que serão criados:

AmazonECS_FullAccess
AmazonEC2ContainerRegistryFullAccess
AmazonVPCReadOnlyAccess
IAMFullAccess
CloudWatchLogsFullAccess
AmazonS3FullAccess

Nota de segurança: Em um ambiente produtivo, o ideal é criar uma policy customizada com o princípio do menor privilégio, concedendo apenas as permissões estritamente necessárias. Para fins de estudo, as managed policies acima simplificam o setup.

Após criar o usuário, gere um Access Key (IAM > Users > Security credentials > Create access key)
Selecione o caso de uso Command Line Interface (CLI)

Configurando as credenciais localmente

Com o AWS CLI instalado, configure as credenciais:

aws configure

Será solicitado:

AWS Access Key ID: AKIA...
AWS Secret Access Key: wJal...
Default region name: us-east-1
Default output format: json

Isso cria o arquivo ~/.aws/credentials que o Terraform utilizará automaticamente via o provider AWS. Com isso feito, o Terraform tem autorização para provisionar os recursos que definiremos a seguir.

Infraestrutura como Código com Terraform

Antes de qualquer pipeline rodar, a infraestrutura precisa existir. Com o Terraform, declaramos todos os recursos AWS em arquivos .tf e provisionamos com um único comando.

Recursos Provisionados

# Provider AWS
provider "aws" {
  region = "us-east-1"
}

# Repositório ECR para armazenar imagens Docker
resource "aws_ecr_repository" "app_repository" {
  name = "minha-app-repository"
}

# Cluster ECS
resource "aws_ecs_cluster" "app_cluster" {
  name = "minha-app-cluster"
}

IAM Role para Tarefas ECS

O ECS precisa de uma role para puxar imagens e enviar logs:

resource "aws_iam_role" "ecs_task_execution_role" {
  name = "ecs-task-execution-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action    = "sts:AssumeRole"
      Effect    = "Allow"
      Principal = { Service = "ecs-tasks.amazonaws.com" }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "ecs_policy" {
  role       = aws_iam_role.ecs_task_execution_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
}

Task Definition (Fargate)

Aqui definimos como o container será executado:

resource "aws_ecs_task_definition" "app_task" {
  family                   = "minha-app-task"
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu                      = "256"
  memory                   = "512"
  execution_role_arn       = aws_iam_role.ecs_task_execution_role.arn

  container_definitions = jsonencode([{
    name      = "app"
    image     = "${aws_ecr_repository.app_repository.repository_url}:latest"
    portMappings = [{
      containerPort = 8080
      hostPort      = 8080
    }]
    logConfiguration = {
      logDriver = "awslogs"
      options = {
        "awslogs-group"         = "/ecs/minha-app"
        "awslogs-region"        = "us-east-1"
        "awslogs-stream-prefix" = "ecs"
      }
    }
  }])
}

ECS Service

O service mantém o container rodando e gerencia o deploy:

resource "aws_ecs_service" "app_service" {
  name            = "minha-app-service"
  cluster         = aws_ecs_cluster.app_cluster.id
  task_definition = aws_ecs_task_definition.app_task.arn
  desired_count   = 1
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = data.aws_subnets.default.ids
    security_groups  = [aws_security_group.app_sg.id]
    assign_public_ip = true
  }
}

OIDC: Autenticação Sem Credenciais Estáticas

Este é um dos pontos mais importantes da arquitetura. Em vez de armazenar AWS_ACCESS_KEY e AWS_SECRET_KEY como secrets no GitHub, usamos OIDC (OpenID Connect) para que o GitHub Actions troque um token temporário por credenciais AWS.

# Registra o GitHub como provedor OIDC na AWS
resource "aws_iam_openid_connect_provider" "github" {
  url             = "https://token.actions.githubusercontent.com"
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = ["ffffffffffffffffffffffffffffffffffffffff"]
}

# Role que o GitHub Actions vai assumir
resource "aws_iam_role" "github_actions_role" {
  name = "github-actions-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = {
        Federated = aws_iam_openid_connect_provider.github.arn
      }
      Action = "sts:AssumeRoleWithWebIdentity"
      Condition = {
        StringEquals = {
          "token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
        }
        StringLike = {
          "token.actions.githubusercontent.com:sub" = "repo:meu-usuario/meu-repo:ref:refs/heads/main"
        }
      }
    }]
  })
}

Por que isso importa? Credenciais estáticas são um risco de segurança. Com OIDC, as credenciais são temporárias e o acesso é restrito a uma branch específica de um repositório específico. Mesmo que alguém tenha acesso ao repositório, não consegue assumir a role a partir de outra branch.

Dockerfile Multi-Stage

Usamos um build multi-stage para separar o ambiente de compilação do ambiente de execução, resultando em uma imagem final menor e mais segura:

# Stage 1: Build
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY ["MeuProjeto/MeuProjeto.csproj", "MeuProjeto/"]
RUN dotnet restore "MeuProjeto/MeuProjeto.csproj"
COPY . .
WORKDIR "/src/MeuProjeto"
RUN dotnet build -c Release -o /app/build

# Stage 2: Publish
FROM build AS publish
RUN dotnet publish -c Release -o /app/publish /p:UseAppHost=false

# Stage 3: Runtime
FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS final
WORKDIR /app
EXPOSE 8080
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "MeuProjeto.dll"]

Benefícios do multi-stage:

A imagem final contém apenas o runtime, não o SDK completo
Reduz significativamente o tamanho da imagem
O código-fonte não fica presente na imagem de produção

Pipeline de CI

A primeira pipeline roda automaticamente quando um Pull Request é aberto contra a branch main. Seu objetivo é validar que o código compila e que os testes passam.

name: PR Validation

on:
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '10.0.x'

      - name: Restore
        run: dotnet restore MinhaSolution.sln

      - name: Build
        run: dotnet build MinhaSolution.sln --no-restore -c Release

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '10.0.x'

      - name: Run Tests with Coverage
        run: |
          dotnet test MinhaSolution.sln \
            --collect:"XPlat Code Coverage" \
            --results-directory ./coverage

O que acontece nesta pipeline:

Job build — Compila a solução para garantir que não há erros de compilação
Job test — Roda os testes unitários com cobertura de código usando Coverlet

Separar em dois jobs traz clareza: se o build falha, você sabe que é erro de compilação. Se o test falha, o código compila mas tem um bug.

Protegendo a Branch Main

Com a pipeline de CI configurada, é fundamental garantir que nenhum código chegue à main sem passar pela validação. Para isso, configuramos uma branch protection rule no GitHub.

Acesse Settings > Branches > Add branch protection rule no seu repositório e configure:

Branch name pattern: main
Marque Require a pull request before merging — impede push direto na main
Marque Require status checks to pass before merging — bloqueia o merge até que os checks passem
Em Status checks that are required, busque e adicione os jobs da pipeline de CI:
- build
- test

Nota: Na primeira vez que configurar, os status checks podem não aparecer na busca. Eles só ficam disponíveis após a pipeline rodar pelo menos uma vez no repositório. Abra um PR de teste para que os checks sejam registrados.

Configurando as Secrets no GitHub

Antes de configurar a pipeline de deploy, é necessário cadastrar as secrets no repositório do GitHub. A pipeline de CD depende delas para autenticar na AWS e saber para onde enviar a imagem Docker.

Acesse Settings > Secrets and variables > Actions > New repository secret no seu repositório e crie as seguintes secrets:

Secret	Valor	Exemplo
`AWS_ROLE`	O ARN completo da IAM Role criada para o GitHub Actions	`arn:aws:iam::123456789012:role/github-actions-role`
`ECR_REPOSITORY`	A URI completa do repositório ECR (não apenas o nome)	`123456789012.dkr.ecr.us-east-1.amazonaws.com/minha-app-repository`
`AWS_ACCOUNT_ID`	O ID numérico da sua conta AWS	`123456789012`

Atenção: Um erro comum é colocar apenas o nome do repositório ECR (ex: minha-app-repository) na secret ECR_REPOSITORY. O valor correto é a URI completa que inclui o domínio do ECR. Você pode obter essa URI no console da AWS em ECR > Repositories ou via CLI:

aws ecr describe-repositories --repository-names minha-app-repository \
  --query "repositories[0].repositoryUri" --output text

Da mesma forma, a secret AWS_ROLE deve conter o ARN (Amazon Resource Name) completo da role, não apenas o nome. Para consultar:

aws iam get-role --role-name github-actions-role \
  --query "Role.Arn" --output text

Com as secrets configuradas, a pipeline de deploy consegue autenticar via OIDC, fazer push da imagem para o ECR e disparar o deploy no ECS.

Pipeline de CD

Quando o PR é aprovado e mergeado na main, a pipeline de deploy entra em ação:

name: Build and Deploy

on:
  push:
    branches: [main]

permissions: #permissões necessárias para autenticação OIDC
  id-token: write
  contents: read 

env:
  AWS_REGION: us-east-1

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS Credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ${{ env.AWS_REGION }}

      - name: Login to Amazon ECR
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build Docker Image
        run: docker build -t minha-app .

      - name: Tag Image
        run: docker tag minha-app:latest ${{ secrets.ECR_REPOSITORY }}:latest

      - name: Push to ECR
        run: docker push ${{ secrets.ECR_REPOSITORY }}:latest

      - name: Deploy to ECS
        run: |
          aws ecs update-service \
            --cluster minha-app-cluster \
            --service minha-app-service \
            --force-new-deployment

O que acontece nesta pipeline:

Autenticação OIDC — O GitHub troca seu token JWT por credenciais AWS temporárias
Login no ECR — Autentica o Docker no registro da AWS
Build e Push — Constrói a imagem Docker e envia para o ECR
Deploy — Dispara um novo deployment no ECS, que puxa a imagem atualizada e substitui o container antigo

O --force-new-deployment garante que o ECS vai iniciar uma nova task mesmo que a tag da imagem (latest) não tenha mudado.

Acessando a Aplicação após o Deploy

Após a pipeline de CD concluir com sucesso, a aplicação estará rodando no ECS Fargate. Como configuramos assign_public_ip = true no Terraform, a task recebe um IP público que pode ser usado para acessar a API.

Obtendo o IP público pelo Console AWS

Acesse ECS > Clusters > minha-app-cluster
Clique na aba Tasks
Clique na task em execução (status RUNNING)
Na seção Network, copie o Public IP
Acesse no navegador: http://<PUBLIC_IP>:8080

Obtendo o IP público via CLI

# 1. Obtenha o ARN da task em execução
TASK_ARN=$(aws ecs list-tasks \
  --cluster minha-app-cluster \
  --service-name minha-app-service \
  --query "taskArns[0]" --output text)

# 2. Obtenha o ID da interface de rede (ENI)
ENI_ID=$(aws ecs describe-tasks \
  --cluster minha-app-cluster \
  --tasks $TASK_ARN \
  --query "tasks[0].attachments[0].details[?name=='networkInterfaceId'].value" \
  --output text)

# 3. Obtenha o IP público
aws ec2 describe-network-interfaces \
  --network-interface-ids $ENI_ID \
  --query "NetworkInterfaces[0].Association.PublicIp" \
  --output text

Importante: O IP público muda toda vez que uma nova task é criada (ou seja, a cada deploy). Para um ambiente produtivo, o ideal é utilizar um Application Load Balancer (ALB) ou um domínio com Route 53 apontando para o serviço ECS, garantindo um endereço fixo. Para fins de estudo, o IP público direto é suficiente.

Segurança: OIDC em Detalhe

Vale reforçar a importância do OIDC neste fluxo. O modelo tradicional funciona assim:

❌ Modelo Tradicional:
   GitHub Secrets → AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY
   - Credenciais estáticas que nunca expiram
   - Se vazadas, acesso total até serem rotacionadas manualmente

Com OIDC:

✅ Modelo OIDC:
   GitHub Actions → JWT Token → AWS STS → Credenciais Temporárias
   - Credenciais expiram automaticamente
   - Escopo restrito: apenas uma branch de um repositório específico
   - Sem segredos de longa duração armazenados

A configuração requer:

Registrar o GitHub como OIDC Provider na AWS (via Terraform)
Criar uma IAM Role com trust policy apontando para o repositório
No workflow, usar permissions: id-token: write e a action configure-aws-credentials com role-to-assume

Fluxo Completo: Do Commit ao Deploy

Resumindo o ciclo de vida de uma mudança:

1. git checkout -b feature/minha-feature
2. # Desenvolve e commita
3. git push origin feature/minha-feature
4. # Abre Pull Request → Dispara pr-validation.yml
   │
   ├── ✅ Build compila com sucesso
   └── ✅ Testes passam com cobertura
   │
5. # Code review + Aprovação
6. # Merge na main → Dispara build-and-deploy.yml
   │
   ├── 🔐 Autenticação via OIDC
   ├── 🐳 Build da imagem Docker (multi-stage)
   ├── 📦 Push para o ECR
   └── 🚀 Deploy no ECS Fargate
   │
7. # Nova versão rodando em produção

Considerações Finais

Este setup demonstra como é possível construir uma pipeline profissional de CI/CD com ferramentas modernas e boas práticas:

Infraestrutura como Código — Toda a infraestrutura é versionada e reproduzível
Autenticação Keyless — OIDC elimina o risco de credenciais estáticas
Serverless Containers — Fargate remove a necessidade de gerenciar servidores
Separação CI/CD — Validação em PRs e deploy apenas na main
Imagens otimizadas — Multi-stage build reduz a superfície de ataque

O custo de infraestrutura para um setup como esse é mínimo — com Fargate usando 0.25 vCPU e 512MB de memória, o custo fica na faixa de poucos dólares por mês para ambientes de estudo e projetos pequenos.

A barreira de entrada para CI/CD profissional diminuiu muito. Ferramentas como GitHub Actions e Terraform tornam acessível o que antes exigia equipes dedicadas de DevOps. O importante é começar simples, entender cada peça, e evoluir conforme a necessidade.

Este artigo foi escrito com base em um projeto prático de estudo. Todo o código-fonte está disponível publicamente neste repositório do GitHub.

[Boost]

Fernando Andrade — Thu, 12 Feb 2026 23:14:12 +0000

API vs Event Streaming: O Que Muda Para Quem Testa? - DEV Community

✨ Oi, gente! Recentemente, tenho pensado bastante em como contribuir para a comunidade de QA e...

dev.to

[Boost]

Fernando Andrade — Wed, 24 Dec 2025 12:22:42 +0000

Alicia Marianne 🇧🇷

Dec 23 '25

From Genin to Kage - Understanding the Test Pyramid with Naruto

#testing #beginners #basic #automation

Comments 5

4 min read

[Boost]

Fernando Andrade — Fri, 12 Dec 2025 23:55:45 +0000

vitoriazzp

Dec 8 '25

8 formas de fazer networking em Tecnologia

#productivity #networking #tutorial

Comments

3 min read

Testes de integração com containers

Fernando Andrade — Thu, 02 Mar 2023 23:43:41 +0000

Tabela de conteúdo

1. Introdução
2. Requisitos
3. Conteúdo
4. Consideração final

1. Introdução

Durante o desenvolvimento de software é essencial realizamos testes. Testes de integração permite que todo fluxo da aplicação seja testada, desde da sua infraestutura até as chamadas da suas APIs, dessa forma garantindo que entregue o que seja esperado e tornando-se mais fácil de identificar erros que podem existir durante as chamadas de suas APIs.

Geralmente quando realizamos testes de integração é utilizado um DbInMemory(Um banco de dados na memória funciona como um banco de dados comum, mas o conteúdo é armazenado na memória em vez de no disco), porém, injetar dados em memória não nos traz um cenário real de uma aplicação rodando. Utilizar um container docker nos permite subir um banco de dados temporariamente para execução dos casos de teste e com isso conseguimos replicar um cenário real de uma aplicação rodando em conjunto com um banco de dados.

Este artigo será um pouquinho longo. Assumindo que você já tenha um conhecimento básico com .NET. Este é um tutorial de como configurar uma aplicação em .NET 6 ou superior para subir uma instância do docker e os testes serem capazes de interagir com um banco de dados, fazendo uso do package Testcontainers para subir a instância. Para este exemplo não foi utilizado nenhum padrão de projeto popular, mantendo o mais simples possível. Você pode encontrar o source do código neste link

2. Requisitos

Para este tutorial você precisa ter

3. Conteúdo

Considerando que já tenha uma experiência prévia com C# e .NET o código está simples para entendimento. Temos uma solução com dois projetos, sendo um a webapi e o outro projeto de teste, com a seguinte estrutura:

TodoApi

├── appsettings.Development.json
├── appsettings.json
├── Context
│   ├── AppContext.cs
│   └── IAppContext.cs
├── Controllers
│   └── TodoController.cs
├── Models
│   └── Todo.cs
├── Program.cs
├── Properties
│   └── launchSettings.json
└── TodoApi.csproj

TodoApiIntegrationTest

├── Setup
│   ├── ClientFixture.cs
│   ├── SeedCreator.cs
│   └── WebApiFactoryConfig.cs
├── TodoApiIntegrationTest.csproj
├── TodoControllerTest.cs
└── Usings.cs

Entendo a webapi

Iniciando pela webapi temos:

Models/Todo.cs: Entidade que é representada no banco de dados.

public class Todo
{
    public int Id {get; set;}
    public string? Title {get; set;}
    public bool Done {get; set;}
}

Context/IAppContext.cs: O IAppContext.cs representa o contrato para a nossa classe abstrata AppContext.

public interface IAppContext
{
    DbSet<Todo> Todos {get; set;}
}

Context/AppContext.cs: O AppContext.cs representa a definição da classe abstrata da nossa interface IAppContext.

public class AppDbContext : DbContext, IAppContext
{
    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) {}

    public DbSet<Todo> Todos {get; set;}
}

Controller/TodoController.cs: Nele contém os endpoints, e estamos injetando por dependência o Context do banco diretamente pela simplicidade.

[ApiController]
[Route("api/[controller]")]
public class TodoController : ControllerBase
{
    private readonly AppDbContext _context;

    public TodoController(AppDbContext context)
    {
        _context = context;
    }

    [HttpGet]
    public async Task<ActionResult<int>> GetAllTodo()
    {
       var result = await _context.Todos
        .AsNoTracking()
        .ToListAsync();

       return Ok(result);
    }

    [HttpGet("{id}")]
    public async Task<ActionResult<int>> GetTodoById(int id)
    {
       var result = await _context.Todos
        .AsNoTracking()
        .FirstOrDefaultAsync(todo => todo.Id == id);

       return Ok(result);
    }

    [HttpPost]
    public async Task<ActionResult<int>> CreateTodo(Todo todo)
    {
        try
        {
            await _context.Todos.AddAsync(todo);
            await _context.SaveChangesAsync();
            return Created("", todo.Id);
        }
        catch(Exception ex)
        {
            return Ok(ex);
        }
    }


}

Program.cs: Responsável por registrar e resolver as dependências do projeto. A partir do .NET 6 não há a necessidade de uma class statup e a aplicação é iniciada atráves do top level statements.
No Program.cs é implementado o context, passando a conexão com o banco e usando para este exemplo o provedor Npgsql e o registro do IAppContext para conseguirmos utilizar injeção de dependência, e, além do Context é adicionado uma classe partial, fazemos isso porque a aplicação está sendo iniciada por top level statement, para os testes de integração é utilizado o WebApplicationFactory que receber um classe Program, utilizar uma class partial permite expor o conteúdo do Program.cs

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var connection = builder.Configuration.GetConnectionString("DefaultConnection");
builder.Services.AddDbContext<AppDbContext>(options =>
        options.UseNpgsql(connection).UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking));

builder.Services.AddScoped<IAppContext>(provider => provider.GetRequiredService<AppDbContext>());
var app = builder.Build();

app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();
app.Run();

public partial class Program { }

Entendo o projeto de teste

Agora iremos configurar o projeto de testes, neste exemplo faço uso de Fixture(abordagem de subir uma instância da classe de teste para cada teste executado, dessa forma qualquer código inserido no construtor da classe de teste será executado para cada teste individual) afim de evitar repetição de código e deixar mais limpo possível.

WebApiFactoryConfig.cs

No WebApiFactoryConfig.cs vamos utilizar o WebApplicationFactory para criar uma instância da nossa classe Program
Para classe é criado dois types genericos para facilitar a criação da Fixture. Utilizando o TestContainer é temos uma propriedade _container que irá ser responsável por criar a instância do banco de dados utilizando uma imagem docker. Em seguida fazemos uma nova implementação do método ConfigureWebHost através do override para implementar nossa conexão da imagem docker, além disso é adicionado também o SeedCreator para adicionar alguns dados para os testes.

public class WebApiFactoryConfig<TProgram, TDbContext> :
    WebApplicationFactory<TProgram>, IAsyncLifetime where TProgram :
        class where TDbContext : DbContext
{
    private readonly TestcontainerDatabase _container =
        new TestcontainersBuilder<PostgreSqlTestcontainer>()
            .WithDatabase(new PostgreSqlTestcontainerConfiguration
            {
                Database = "todo_db",
                Password = "supersecuritypassword",
                Username = "postgres"
            })
            .WithImage("postgres:11")
            .WithCleanUp(true)
            .Build();

    protected override void ConfigureWebHost(IWebHostBuilder builder)
    {
        builder.ConfigureTestServices(services =>
        {
            var descriptor = services.SingleOrDefault( d => d.ServiceType == typeof(DbContextOptions<TDbContext>));
            if (descriptor != null) services.Remove(descriptor);
            services.AddDbContext<TDbContext>(options => { options.UseNpgsql(_container.ConnectionString); });


            var serviceProvider = services.BuildServiceProvider();

            using var scope = serviceProvider.CreateScope();
            var scopedServices = scope.ServiceProvider;
            var context = scopedServices.GetRequiredService<TDbContext>();
            context.Database.EnsureCreated();

            services.AddTransient<SeedCreator>();
        });
    }

    public async Task InitializeAsync() => await _container.StartAsync();

    public new async Task DisposeAsync() => await _container.DisposeAsync();
}

SeedWork.cs

O SeedWork.cs é uma classe que há alguns métodos para adicionar dados no database da imagem docker

private readonly AppDbContext _context;

    public SeedCreator(AppDbContext context)
    {
        _context = context;
    }

    public async Task AddTodo()
    {
        var todos = new List<Todo>
        {
            new Todo { Done = false, Title = "Fazer Compras" },
            new Todo { Done = false, Title = "Areia para caixinha dos gatos" },
            new Todo { Done = false, Title = "Lavar as roupas" },
            new Todo { Done = true, Title = "Ir ao shopping" },
        };

        await _context.Todos.AddRangeAsync(todos);
        await _context.SaveChangesAsync();
    }

ClientFixture

Essa classe é responsável por disponibilizar algumas propriedades e métodos de chamadas HTTP para nossos controler de teste, como também instanciar o WebAppFactory recebendo a classe Program e a classe do context AppDbContext

public class ClientFixture : IClassFixture<WebApiFactoryConfig<Program, AppDbContext>>
{
    private readonly WebApiFactoryConfig<Program, AppDbContext> Factory;
    public readonly HttpClient Client;
    public readonly SeedCreator SeedWork;
    public readonly AppDbContext dbContext;

    public ClientFixture(WebApiFactoryConfig<Program, AppDbContext> factory)
    {
        Factory = factory;
        var scope = factory.Services.CreateScope();
        dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>();
        Client = factory.CreateClient();
        SeedWork = scope.ServiceProvider.GetRequiredService<SeedCreator>();
    }

    public async Task<HttpResponseMessage> AsPostAsync<T>(string url, T body)
    {
        var json = JsonSerializer.Serialize(body);
        var buffer = System.Text.Encoding.UTF8.GetBytes(json);
        var byteContent = new ByteArrayContent(buffer);
        byteContent.Headers.ContentType = new MediaTypeHeaderValue("application/json");
        return await Client.PostAsync(url, byteContent);
    }

    public async Task<HttpResponseMessage> AsPutAsync<T>(string url, T body)
    {
        var json = JsonSerializer.Serialize(body);
        var buffer = System.Text.Encoding.UTF8.GetBytes(json);
        var byteContent = new ByteArrayContent(buffer);
        byteContent.Headers.ContentType = new MediaTypeHeaderValue("application/json");
        return await Client.PutAsync(url, byteContent);
    }

    public async Task<HttpResponseMessage> AsGetAsync(string url)
        => await Client.GetAsync(url);

    public async Task<HttpResponseMessage> AsDeleteAsync(string url)
        => await Client.DeleteAsync(url);
}

TodoApiIntegrationTest.cs

No TodoApiIntegrationTest.cs herda o ClientFixture, é passado no construtor a classe Program e AppDbContext para instanciar o WebAppFactory. Temos dois casos de teste, com os métodos de chamada HTTP criado no ClienFixture e com isto conseguimos chamar as rotas da API, em seguida é garantir que o resultado da chamada esteja como esperado fazendo uso dos Asserts.

public class TodoControllerTest : ClientFixture
{
    public TodoControllerTest(WebApiFactoryConfig<Program, AppDbContext> factory) : base(factory) {}


    [Fact]
    public async Task Create_New_Todo_Return_200OK()
    {
        // Arrange
        Todo @todo = new()
        {
            Done= false,
            Title = "Novo todo",
        };

        // Act
        var response = await AsPostAsync("api/Todo/", todo);
        var resultId = Int32.Parse(await response.Content.ReadAsStringAsync());
        // Assert
        Assert.True(resultId > 0);
        Assert.Equal(HttpStatusCode.Created, response.StatusCode);
    }

    [Fact]
    public async Task Get_Todo_Return_200OK()
    {
        // Arrange
        await SeedWork.AddTodo();

        // Act
        var response = await AsGetAsync("api/Todo/");
        var result = await response.Content.ReadAsStringAsync();

        // Assert
        List<Todo>? todos =  JsonSerializer.Deserialize<List<Todo>>(result);
        var assertresult = todos?.Count == 5;

        Assert.Equal(HttpStatusCode.OK, response.StatusCode);
        Assert.True(assertresult);
    }
}

Neste caso de teste foi realizado chamada do SeedWork e logo em seguida é possível obter os dados que foram adicionados no container 😁.

4. Consideração final

Testes de integração com container facilita a inicialização de um banco de dados completo para fins de teste, tornando-se perfeito para testes de integração!

Espero que este artigo tenha sido útil e básico para o entendimento de todos, obrigado se você leu até aqui.

Como usar uma classe Fixture com xUnit

Fernando Andrade — Sun, 13 Feb 2022 13:40:22 +0000

Oi pessoal, tudo certo? Gostaria de compartilhar uma dica que acho interessante para quem escreve testes utilizando o xUnit, que é o uso de Fixture. Para quem está iniciando nessa jornada de testes unitários assim como eu é normal escrevemos dessa forma:

[Fact]
public void TesteAreaDoQuadrado()
{
    Area area = new();
    int result = area.Quadrado(5);
    Assert.Equal(25, result);
}

[Fact]
public void TesteAreaDoTriangulo()
{
    Area area = new();
    int result = area.Triangulo(10, 5);
    Assert.Equal(25, result);
}

[Fact]
public void TesteAreaDoRetangulo()
{
    Area area = new();
    int result = area.Retangulo(5, 3);
    Assert.Equal(15, result);
}

O que é normal no início, mas podemos que notar que para cada teste estamos instanciando a classe Area repetidamente para podermos utilizar os métodos nos casos de teste, isso significa que toda vez que um de nossos testes na mesma classe precisa ser executado, uma nova instância dessa classe é criada e ter uma Fixture resolve essa necessidade. Fixture é uma classe que compartilha todos os métodos de teste, nessa classe você pode configurar tudo que for necessário, assim, evitamos de instanciar classes para cada teste individual e melhorando o tempo de execução dos testes.

Criando a Fixture

Dentro da classe de teste, criamos uma outra classe, no meu caso AreaFixture que irá ter como propriedade a classe Area já sendo instanciada:

public class AreaFixture
{
    public Area Area => new();
}

Após isso para compartilhar essa instância entre todos os nossos testes adicionamos uma interface para nossa classe de teste usando o IClasseFixture, a interface IClasseFixture espera receber a uma classe Fixture nesse caso a AreaFixture:

public class AreasTest : IClassFixture<AreaFixture>

Ultimo passo é via injeção de dependência adicionamos ao construtor da classe AreaTest a classe AreaFixture

public class AreasTest : IClassFixture<AreaFixture>
    {
        private readonly AreaFixture _areaFixture;
        public AreasTest(AreaFixture areaFixture)
        {
            _areaFixture = areaFixture;
        }

Agora quando o xUnit executar os testes irá ser criado uma instância apenas e todos os nossos testes agora possuem acesso aos métodos da classe Area atráves do campo _areaFixture.Area .

[Fact]
public void TesteAreaDoQuadrado()
{
    Area area = _areaFixture.Area;
    int result = area.Quadrado(5);
    Assert.Equal(25, result);
}

[Fact]
public void TesteAreaDoTriangulo()
{
    Area area = _areaFixture.Area;
    int result = area.Triangulo(10, 5);
    Assert.Equal(25, result);
}

[Fact]
public void TesteAreaDoRetangulo()
{
    Area area = _areaFixture.Area;
    int result = area.Retangulo(5, 3);
    Assert.Equal(15, result);
}

Código completo

Criando active classes com EJS

Fernando Andrade — Tue, 26 Oct 2021 11:04:14 +0000

EJS é uma linguagem de template que utiliza javascript para gerar HTML, além de compartilhar templates e dados com outras páginas. Este post é para demonstrar como utilizar uma class active para demonstrar ao user a página que está sendo acessada no momento em uma aplicação Node utilizando EJS como template engine.

Boilerplate

Clicando aqui você pode clonar um boilerplate com a configuração mínina para a aplicação funcionar.

Primeiros passos e estrutura

Com a aplicação rodando vamos lá... Apenas para entender, olhando o projeto podemos notar a seguinte estrutura:

Views - diretório que a aplicação olha para encontrar os arquivos ejs.
Public - diretório que olha para os arquivos estáticos.
Routes - diretório para definir qual rota irá redenrizar o template.

Iremos mexer apenas na public e views. Adicione no style.css o seguinte css:

.nav-link {
    text-decoration: none;
    font-size: 20px;
    color: #fff;
    background: #333;
}

.nav-link:hover {
    background: purple;
}

.active {
    background: purple;
}

Obtendo active class dinâmico

Em seguida para obtermos o resultado de um active class dinâmico no EJS vamos fazer o uso de variáveis e partials, partials é o conceito de criar templates reutilizáveis para evitar repetição de código e usar em outras views. No diretório views dentro de partials crie um arquivo chamado nav.ejs com o seguinte código:

<nav>
    <a class="<%= active === 'Home' ? 'nav-link active' : 'nav-link'%>" href="/">Home</a>
    <a class="<%= active === 'Sobre' ? 'nav-link active' : 'nav-link'%>" href="/sobre">Sobre</a>
    <a class="<%= active === 'Contato' ? 'nav-link active' : 'nav-link'%>" href="/contato">Contato</a>
</nav>

Criamos um arquivo .ejs que é um template reusável. A sintaxe do EJS faz uso do <%= %> para definir suas variáveis e criar condicionais dentro do campo, loops e output de variáveis, então dentro do atributo class fazendo o uso da sintaxe do ejs nós criamos uma variável chamada active e estamos comparando o valor dela com Home, Sobre e Contato usando uma condicional ternária, se um for verdadeiro irá mostrar qual link está ativo e os restantes estaram normais.

Finalizando

Agora que temos o nosso template reutilizavél com as condições definidas vamos incluir nas nossas páginas. Para incluir um template EJS em uma página utilizamos o <%- include(caminho/relativo/do/arquivo) %> então agora adicionaremos o template para cada página dentro do diretório pages, dentro de cada página adicione logo acima da tag h2:

<%- include('../partials/nav', {active: 'Sobre' }); %>

Note que após passar o caminho relativo da partial estamos passando para a variável active definida no nav.ejs um valor, essa é a forma de definir um valor a uma variável no EJS quando importado em outra view.

Por fim depois de ter incluido para todas as páginas o template e definido o para a variável active seu respectivo valor iremos obter o seguinte resultado final.

Espero que tenham gostado, esse foi o meu primeiro post então dicas de como eu possa estar melhorando e melhorando este código são bem vindas e até breve pessoal 💜.