DEV Community: Guilherme

Do Anti-Vibecoding ao Caos: A Saga do "Ficha Monstra"

Guilherme — Fri, 26 Dec 2025 15:36:45 +0000

O projeto "Ficha Monstra" nasceu de uma mistura de necessidade e impulso: eu comprei um VPS durante a black friday por puro consumismo, 2) eu queria escrever e aprender mais sobre usar a inteligência artificial de uma maneira legal no desenvolvimento de software e 3) eu estava cansado de perder minhas fichas de papel na caixinha de fichas de treinos na academia.

Ai nasceu o Ficha Monstra, nome que veio do gemini.

A premissa era criar uma stack "anti-vibecoding": queria estrutura e controle. Escolhi Blazor .NET Core, Identity, EF e Semantic Kernel no Azure.

A Fase da Ordem Comecei disciplinado. Usei o Gemini apenas para brainstorming e geração de HTML/CSS, mas mantive o controle arquitetural. Criei a solução .NET manualmente (para evitar o vício das IAs em bibliotecas antigas) e usei o Spec Kit para criar uma "Constituição" do projeto, impondo regras rígidas ao modelo. O resultado? Um MVP honesto e funcional entregue em tempo recorde.

Telas, autenticação, telas de criação, detalhe, listagem, paginação, integração com redis cache, eu fiz também um agente integrado com Plugins do Semantic Kernel que é capaz de ver os exercícios na base e sugerir treinos baseado nas informações que o usuário enviou, validações, testes unitários e integrados, tudo isso em 1 dia.

É verdade que o código estava longe da qualidade desejada.

A Queda para o Vibecoding O problema de ver tudo funcionando rápido é que o poder sobe à cabeça. A sensação de invencibilidade me fez abandonar o plano original. De repente, eu estava improvisando outras features que não estavam planejadas como gamificação, múltiplos dashboards, admin.

O rigor técnico desapareceu. Parei de criticar o código gerado e o resultado foi inevitável: o projeto, antes até que bonitinho, degradou-se rapidamente.

O Aprendizado Apesar do caos no código final, houve um brilho técnico: integrei o Playwright com o Gemini via MCP. Ver o modelo "olhando" para a interface e rodando seus próprios testes foi animal.

O Spec Kit é uma surpresa, apesar de ser um pouquinho complicado de entender, ele realmente é uma ferramenta que auxilia e da controle na hora de criação das features.

As vezes é melhor botar a mão no código e resolver problemas do que escrever mais um prompt e esperar a solução. É preciso saber identificar quando o modelo está patinando no gelo porque a verdade é que quem vai patinar é você e não o modelo.

No fim, o Ficha Monstra me ensinou que a IA acelera a construção, mas também acelera a criação de dívida técnica se você baixar a guarda. O código gerado é realmente feio e ruim, e é preciso se tornar mais revisor do que o codificador. E saber as bases da engenharia de software é o que faz a diferença.

E me deu uma sensação meio estranha para 2026 de que nada será como antes, MESMO.

Transforme seus testes de .NET em um painel visual com Coverlet + GitHub Actions

Guilherme — Fri, 25 Jul 2025 20:13:14 +0000

Precisava, rápido, de um relatório de cobertura de testes para um projeto meu.

Um projeto simples feito em .NET, com alguns testes unitários, e que, a cada pull request na branch main, fosse gerado um relatório de forma que eu pudesse divulgar entre minha equipe (no caso eu mesmo e meus pensamentos).

Um detalhe importante: meu repositório no GitHub é privado, e se eu quiser usar o GitHub Pages, preciso torná-lo público, o que está fora de questão.

Por que usar o Coverlet?

Vamos gerar o relatório de cobertura de testes com o Coverlet, porque:

Funciona com os principais frameworks de teste: xUnit, NUnit e MSTest
É open source, leve e amplamente adotado pela comunidade .NET

🔗 https://github.com/coverlet-coverage/coverlet

E para transformar os dados brutos de cobertura em relatórios legíveis:

Por que usar o ReportGenerator?

Converte os arquivos de cobertura (como o coverage.xml gerado pelo Coverlet) em relatórios HTML interativos e fáceis de visualizar
É leve, rápido e gratuito

Criando um workflow no GitHub Actions

name: Code Coverage

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repo
        uses: actions/checkout@v3

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

      - name: Restore dependencies
        run: dotnet restore

      - name: Run tests with coverage
        run: |
          dotnet test ./tests/MeuProjetoDe.Tests/Domain.Tests.csproj \
            --collect:"XPlat Code Coverage"

      - name: Install ReportGenerator
        run: dotnet tool install --global dotnet-reportgenerator-globaltool

      - name: Generate HTML report
        run: |
          reportgenerator \
            -reports:"**/coverage.cobertura.xml" \
            -targetdir:"coveragereport" \
            -reporttypes:Html

      - name: Upload coverage report artifact
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coveragereport

Esse workflow vai:

Configurar o ambiente .NET
Restaurar dependências
Executar os testes com o --collect:"XPlat Code Coverage", que ativa o data collector do Coverlet
Instalar o ReportGenerator
Gerar o relatório HTML
Fazer upload do resultado como artefato

Depois de rodar o workflow, o relatório já estará disponível nos artefatos:

Como publicar o relatório no GitHub Pages

Como meu repositório original é privado e pretendo mantê-lo assim, criei um segundo repositório público apenas para servir o relatório via GitHub Pages:

1. Criando um token de acesso

Acesse Developer Settings no GitHub e crie um token com as permissões adequadas:

Guarde esse token, pois ele será necessário para a próxima etapa do workflow.

2. Adicionando o deploy no final do workflow

Adicione o trecho abaixo no final do seu workflow para publicar o conteúdo no branch gh-pages do repositório público:

      - name: Deploy coverage report to MeuProjeto.Coverage repo
        run: |
          git config --global user.name "seu nome"
          git config --global user.email "seu email"
          cd coveragereport
          git init
          git checkout -b gh-pages
          git remote add origin https://x-access-token:${{ secrets.COVERAGE_PUBLISH_TOKEN }}@github.com/{seu-usuario}/{repositorio-publico}.git
          git add .
          git commit -m "feat: atualização automática de cobertura"
          git push --force origin gh-pages

3. Criando e adicionando o token no GitHub

Vá em https://github.com/settings/tokens

Crie um token com permissão de escrita no repositório de destino

Copie o token e adicione no repositório privado (Generioc) em
Settings > Secrets and variables > Actions, como:
COVERAGE_PUBLISH_TOKEN

Pronto. O GitHub Actions agora pode fazer o deploy automaticamente no Pages. ✅

Gerando Relatório de Cobertura de Testes de um projeto em .NET com Coverlet + GitHub Actions

Guilherme — Fri, 25 Jul 2025 20:13:14 +0000

Precisava, rápido, de um relatório de cobertura de testes para um projeto meu.

Um detalhe importante: meu repositório no GitHub é privado, e se eu quiser usar o GitHub Pages, preciso torná-lo público, o que está fora de questão.

Por que usar o Coverlet?

Vamos gerar o relatório de cobertura de testes com o Coverlet, porque:

Funciona com os principais frameworks de teste: xUnit, NUnit e MSTest
É open source, leve e amplamente adotado pela comunidade .NET

🔗 https://github.com/coverlet-coverage/coverlet

E para transformar os dados brutos de cobertura em relatórios legíveis:

Por que usar o ReportGenerator?

Converte os arquivos de cobertura (como o coverage.xml gerado pelo Coverlet) em relatórios HTML interativos e fáceis de visualizar
É leve, rápido e gratuito

Criando um workflow no GitHub Actions

name: Code Coverage

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repo
        uses: actions/checkout@v3

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

      - name: Restore dependencies
        run: dotnet restore

      - name: Run tests with coverage
        run: |
          dotnet test ./tests/MeuProjetoDe.Tests/Domain.Tests.csproj \
            --collect:"XPlat Code Coverage"

      - name: Install ReportGenerator
        run: dotnet tool install --global dotnet-reportgenerator-globaltool

      - name: Generate HTML report
        run: |
          reportgenerator \
            -reports:"**/coverage.cobertura.xml" \
            -targetdir:"coveragereport" \
            -reporttypes:Html

      - name: Upload coverage report artifact
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coveragereport

Esse workflow vai:

Configurar o ambiente .NET
Restaurar dependências
Executar os testes com o --collect:"XPlat Code Coverage", que ativa o data collector do Coverlet
Instalar o ReportGenerator
Gerar o relatório HTML
Fazer upload do resultado como artefato

Depois de rodar o workflow, o relatório já estará disponível nos artefatos:

Como publicar o relatório no GitHub Pages

Como meu repositório original é privado e pretendo mantê-lo assim, criei um segundo repositório público apenas para servir o relatório via GitHub Pages:

1. Criando um token de acesso

Acesse Developer Settings no GitHub e crie um token com as permissões adequadas:

Guarde esse token, pois ele será necessário para a próxima etapa do workflow.

2. Adicionando o deploy no final do workflow

Adicione o trecho abaixo no final do seu workflow para publicar o conteúdo no branch gh-pages do repositório público:

      - name: Deploy coverage report to MeuProjeto.Coverage repo
        run: |
          git config --global user.name "seu nome"
          git config --global user.email "seu email"
          cd coveragereport
          git init
          git checkout -b gh-pages
          git remote add origin https://x-access-token:${{ secrets.COVERAGE_PUBLISH_TOKEN }}@github.com/{seu-usuario}/{repositorio-publico}.git
          git add .
          git commit -m "feat: atualização automática de cobertura"
          git push --force origin gh-pages

3. Criando e adicionando o token no GitHub

Vá em https://github.com/settings/tokens

Crie um token com permissão de escrita no repositório de destino

Copie o token e adicione no repositório privado (Generioc) em
Settings > Secrets and variables > Actions, como:
COVERAGE_PUBLISH_TOKEN

Pronto. O GitHub Actions agora pode fazer o deploy automaticamente no Pages. ✅

Criando testes de integração no ASP.NET core | Parte 1

Guilherme — Sun, 07 Jan 2024 22:05:00 +0000

Uma rápida passada em testes unitários

De modo geral, os testes unitários testam, isoladamente, a menor unidade de um código, ou seja: os métodos e classes sem acesso a banco ou serviços externos.

Os testes unitários são de rápida execução, desenvolvimento, refatoração e detecção de bugs no código.

É bom lembrar que os testes unitários são totalmente mockados, isto é, as implementações das classes mockam acessos a repositórios, serviços etc.

Os testes de integração

Os testes de integração desempenham o papel de avaliar a interação entre diferentes componentes do sistema, a fim de verificar seu funcionamento em conjunto.

É por meio desses testes que asseguramos a consistência das interações entre diversas partes do sistema, validamos fluxos complexos e completos, garantindo assim a qualidade do código como um todo, não se limitando a uma única parte isolada.

Sim, eles são mais complexos de desenvolver e manter, além de serem mais lentos ao serem executados em comparação aos testes de unidade. Isso ocorre porque testam funcionalidades completas, inclusive a persistência dos dados quando aplicável, ou o acesso a serviços externos.

Vamos ao código

Edite o arquivo do projeto da API dando visibilidade da sua api ao testes:

`<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <InvariantGlobalization>true</InvariantGlobalization>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Dapper" Version="2.1.28" />
    <PackageReference Include="Microsoft.AspNetCore.OpenApi" Version="8.0.0" />
    <PackageReference Include="Npgsql" Version="8.0.1" />
    <PackageReference Include="Swashbuckle.AspNetCore" Version="6.4.0" />
  </ItemGroup>

    <ItemGroup>
        <InternalsVisibleTo Include="CheckoutApiTests"/>
    </ItemGroup>
</Project>`

Exponha seu Program.cs adicionando a linha ao final do arquivo:

public partial class Program { }

Crie a classe de testes integrados

namespace CheckoutApiTests
{
    public class CheckoutServiceIntegrationTests : IClassFixture<WebApplicationFactory<Program>>
    {
        private readonly WebApplicationFactory<Program> _sut;
        public CheckoutServiceIntegrationTests(WebApplicationFactory<Program> sut)
        {
            _sut = sut;
        }
    }
}

Sut é um acrônimo para System Under Test

*Opcional: adicione um enviroment variable *

 public CheckoutServiceIntegrationTests(WebApplicationFactory<Program> sut)
 {
     _sut = sut.WithWebHostBuilder(builder =>
     {
         builder.UseEnvironment("Development");
     });
 }

*Crie um teste *

[Fact]
![Criando um teste de integração](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0u3j6ewycp0ec9mjlwz9.gif)


public async Task PostCheckout_ReturnsOkWithInsertedId_WhenValidData()
{
    var client = _sut.CreateClient();

    var checkoutData = new
    {
        CardNumber = "10000011100011",
        UserId = Guid.NewGuid(),
        ExpirationDate = "12/25",
        SecurityCode = "123",
        Amount = 19,
        Currency = "BRL"
    };

    var content = new StringContent(JsonSerializer.Serialize(checkoutData), System.Text.Encoding.UTF8, "application/json");

    var response = await client.PostAsync("/checkout", content);

    Assert.Equal(HttpStatusCode.OK, response.StatusCode);

    var responseContent = await response.Content.ReadAsStringAsync();
    var insertedId = JsonSerializer.Deserialize<Guid>(responseContent);

    Assert.NotEqual(Guid.Empty, insertedId);
}

Hora de rodar os testes

Lembrando que esses testes estão conectados no banco de desenvolvimento, portanto um registro foi criado na tabela:

E agora você sabe como criar testes de integração, hora de botar a mão na massa e criar mais testes.

No próximo artigo vamos utilizar o Testcontainers para criar um banco em tempo de execução dos testes integrados!

Até mais!

Aprendendo e botando em prática com as muitas APIs disponíveis. Um pequeno incentivo pra você.

Guilherme — Tue, 26 Sep 2023 01:23:31 +0000

A dica é óbvia, mas sempre válida: comece pela documentação e leia-a com calma. Os detalhes aqui são importantes.

Lendo e trabalhando com APIs consagradas e disponíveis você deverá aprender coisas como:

Uso básico da API

Ou seja, como fazer solicitações, autenticação, autorização, entender as respostas e como funcionam em diferentes empresas.

Autenticação/Autorização

Compreender os métodos de autenticação e notar que, de maneira geral, as APIs funcionam de forma semelhante, seja com o uso de chaves de API, OAuth, entre outros. Você pode implementar um método de autenticação na sua API com base na documentação de um produto bem estabelecido no mercado.

Escrever documentação

Imagine que você tenha uma tarefa agendada para amanhã que envolve a modificação de um endpoint sem documentação existente. Essa é uma excelente oportunidade para ganhar reconhecimento junto à equipe, mesmo que envolva apenas a documentação desse endpoint. Você já tem exemplos de como documentar uma API. Siga o exemplo!

Um desafio

Considere encapsular as funcionalidades da API em um único lugar usando um "wrapper" (encapsulamento). Nesse caso, pode ser uma ótima ideia reinventar a roda, pois isso permite colocar em prática conceitos importantes, como abstração, testes e legibilidade de código. Além disso, não hesite em dar uma olhada nas soluções já publicadas no GitHub para aprender com os melhores exemplos disponíveis.

Algumas APIs pra você:

Last.fm API: http://www.last.fm/api
Spotify Developer: https://developer.spotify.com/
ANBIMA (Associação Brasileira das Entidades dos Mercados Financeiro e de Capitais): [https://developers.anbima.com.br/pt/documentacao/visao-geral/introducao-a-api/]
Discord Developer Portal: https://discord.com/developers/docs/intro Telegram Bot API: https://core.telegram.org/ Adyen API Explorer: https://docs.adyen.com/api-explorer https://core.telegram.org/ https://docs.adyen.com/api-explorer/