Forem: Inácio Bueno

Playwright Codegen

Inácio Bueno — Thu, 12 Feb 2026 04:27:58 +0000

Playwright é uma das libs de teste end-to-end mais completas disponíveis no mercado: suporte aos principais navegadores, sistemas operacionais, pronto para desenvolvimento local e execução em pipelines de integração.
Esse post não sobre playwight em si, mas sim uma ferramenta dessa lib que me ajudou demais fazendo testes de integração: codegen.
O que é a codegen? Resumindo bem, é uma ferramenta que grava toda a sua ação (clicks do mouse e ações no teclado) na aplicação que você quer testar. Então se você quer testar o fluxo de login, basta iniciar a codegen e fazer o fluxo como se você fosse um usuário comum fazendo login. É tudo tão simples assim? Não, mas é quase lá.

Instalação

Se quiser acompanhar está aqui o passo a passo:
Crie um projeto; entra no diretório; instala o nuget; faz o build

dotnet new xunit -n PlaywrightTests
cd PlaywrightTests
dotnet add package Microsoft.Playwright.Xunit
dotnet build

Depois do build, executa isso para instalar os navegadores

pwsh bin/Debug/net8.0/playwright.ps1 install

Uma alternativa a esse último passo, você pode fazer (não é muito recomendado pois é depreciado e em https://www.nuget.org/packages/Microsoft.Playwright.CLI recomenda você fazer pwsh bin/Debug/net8.0/playwright.ps1 install):

dotnet tool install --global Microsoft.Playwright.CLI
playwright install --with-deps

Eu fiz isso pelo simples motivo de não querer instalar o pwsh agora. Mas você deve fazer o recomendado, eu não. Faça o que eu não faço e seja melhor por nós dois.

Codegen

Vamos logo para ferramenta. Eu estou com uma aplicação blazor (com blueprint) rodando localmente em http://localhost:5000.
Para iniciar o comando mais simples é:

playwright codegen http://localhost:5000/

Isso deve abrir duas janelas aí no seu pc:
1 - Um navegador

2 - Janela Inspeção / gravação

Já de início temos o código:

using Microsoft.Playwright;
using System;
using System.Threading.Tasks;

using var playwright = await Playwright.CreateAsync();
await using var browser = await playwright.Chromium.LaunchAsync(new()
{
    Headless = false,
});
var context = await browser.NewContextAsync();

var page = await context.NewPageAsync();
await page.GotoAsync("http://localhost:5000/");

Que é o setup básico para início do teste. No seu teste de verdade quando for montar sua fixture, o Headless poderia ser false que evitaria que uma janela de navegador fosse "aberta visualmente".

Repare que ele já inicia com a gravação ligada

Então caso não queira testar algo direto na página inicial, você pode parar a gravação, navegar normalmente até onde deseja testar e depois voltar a gravação.

Uma observação antes de continuarmos, talvez você possa ter problemas com certificado, então faça isso:

using Microsoft.Playwright;
using Microsoft.Playwright.Xunit;

namespace PlaywrightTests;

public class MyProjectTestBase : PageTest
{
 public MyProjectTestBase()
    {
        Playwright.Selectors.SetTestIdAttribute("propriedade-test");
    }
    public override BrowserNewContextOptions ContextOptions()
    {
        return new BrowserNewContextOptions
        {
            IgnoreHTTPSErrors = true
        };
    }
}

e no seu teste herança de MyProjectTestBase:

namespace PlaywrightTests;

public class UnitTest1 : MyProjectTestBase
{
    [Fact]
    public void TestName()
    {
        // Given

        // When

        // Then
    }
}

1, 2, 3 teste testando

O nosso setup já foi dado:

await page.GotoAsync("http://localhost:5000/");

falta nosso assert e aqui entra o arsenal do codegen:

Clicando em assert visibility e passando o mouse por cima da pagína ele mostra como ele vai obter o elemento:

e depois de clicar no elemento, já é feito o assert no gerador de código:

await Expect(page.GetByRole(AriaRole.Heading, new() { Name = "Welcome to BlazorBlueprint" })).ToBeVisibleAsync();

O assert text geraria:

await Expect(page.Locator("h1")).ToContainTextAsync("Welcome to BlazorBlueprint");

o assert snapshot:

await Expect(page.Locator("h1")).ToMatchAriaSnapshotAsync("- heading \"Welcome to BlazorBlueprint\" [level=1]");

E cabe a você decidir quais dessas segue mais o padrão de assert você quer fazer no seu código.
Aqui foquei mais na parte do assert, mas vou mostrar também um pouco mais sobre outros aspectos de captura.

Por exemplo num formulário, eu apenas clico em gravar, preencho normalmente e ele gera código:

E grava também ao pressionar teclar e combinações:

Options

Essa parte aqui é bem importante para você executar o codegen com um contexto similiar ao que você teria na sobreescrita do MyProjectTestBase. Por exemplo, se no BrowserNewContextOptions você tem:

return new BrowserNewContextOptions
        {
            IgnoreHTTPSErrors = true,
Locale = "en-US",
        };

no codegen você deve iniciar ele com

playwright codegen --ignore-https-errors --lang "en-US" http://localhost:5000/

E assim para todas as opções (incluindo --test-id-attribute que acho bem interessante no playwright que é definido no Playwright.Selectors.SetTestIdAttribute("propriedade-test"); por exemplo) que você pode encontrar no BrowserNewContextOptions.

Conclusão

Espero que você tenha aprendido alguma coisa que te ajude no seu fluxo de trabalho com codegen. No mais, qualquer dúvida, leia a documentação, converse com o chatgpt, pergunte ao seu líder de equipe, o seu açogueiro de confiança... Se nenhum deles te ajudar, manda uma mensagem lá no meu linkedin.

Quem vigia os vigilantes: uma introdução a testes de mutação

Inácio Bueno — Thu, 26 Jun 2025 00:54:49 +0000

Testes de mutação podem dar ótimos indicadores de como / se os seus testes estão realmente preservando o estado de comportamento original da sua regra de negócio. Neste breve texto irei introduzir conceitualmente o que são testes de mutação e apresentar uma ferramenta para fazer esse tipo de análise.
A ideia é bem simples: mutações são alterações no seu código, e se essas alterações no seu código não reprovarem no seu teste, pode ser que o seu teste seja ruim ou incompleto. Um exemplo rápido, imagine uma função que verifica se alguém é maior de 18 anos:

    public class Verificador
    {
        public bool EhMaiorDeIdade(int idade)
        {
            return idade >= 18;
        }
    }

E que para o teste dessa função você tenha um único teste:

        [Fact]
        public void Deve_Retornar_Verdadeiro_Para_Uma_Idade_Maior_Ou_Igual_18()
        {
            var verificador = new Verificador();

            var resultado = verificador.EhMaiorDeIdade(19);

            Assert.True(resultado);
        }

No primeiro olhar, tudo parece ok, a função é para verificar se é maior de idade, 19 anos seria alguém maior de idade o teste passou, então está tudo certo, certo?! É claro que esse é um exemplo simples e fácil de verificar que não, mas uma modificação (mutação) de "return idade >= 18;" para "return idade > 18;" continuaria fazendo com que o seu teste fosse aprovado, porém essa modificação quebrou a sua regra de negócio mas seu teste - que deveria ser aquilo que te alerta que alterações recentes alteraram crucialmente o comportamento inicialmente definido pela sua regra de negócio - não te diz nada.
Aqui entra o Stryker, uma ferramenta que irá fazer essas mutações no seu código, e para cada mutação que for possível fazer, ela irá executar o teste. Se o seu teste passar com uma mutação (alteração), seu teste está incompleto; Se as mutações fizerem o seu teste reprovar elas, você está no caminho correto; digo "no caminho correto" porque as mutações feitas pela ferramenta tem sua limitações e que mutações/alterações feitas ao decorrer do tempo por programadores reais, têm bem mais sutilezas.
Eu criei aqui dois projetos bem simples, um projeto console e outro é um projeto de testes. Caso queira fazer o mesmo:

dotnet new console -n console.mutation; dotnet new sln -n solucao; dotnet new xunit -n teste.mutation

A ferramenta você pode instalar com:

dotnet tool install -g dotnet-stryker

Entre no diretório do projeto de teste e rode:

dotnet-stryker

No caso do nosso exemplo, teríamos o seguinte resultado pelo terminal:

100.00% │ Testing mutant 2 / 2 │ K 1 │ S 1 │ T 0 │ ~0m 00s │                                                       00:00:02                                                                                                                           
Killed:   1
Survived: 1
Timeout:  0

Mas também tem uma página html disponibilizada para ver com mais detalhes:

O diff em verde no código é a mutação feita pela ferramenta, e como indica no filtro ela foi a mutação que sobreviveu. Como Podemos matar ela? Simples, testando melhor: Se a função verifica se um número é maior ou igual 18, é fácil de ver que nosso teste testa apenas se maior e não se é maior ou igual. Ao teste vamos adicionar:

[Fact]
        public void Deve_Retornar_Verdadeiro_Para_Uma_Idade_Igual_18()
        {
            var verificador = new Verificador();

            var resultado = verificador.EhMaiorDeIdade(18);

            Assert.True(resultado);
        }

O teste completo fica assim:

    public class TesteVerificador
    {
        [Fact]
        public void Deve_Retornar_Verdadeiro_Para_Uma_Idade_Maior_Ou_Igual_18()
        {
            var verificador = new Verificador();

            var resultado = verificador.EhMaiorDeIdade(19);

            Assert.True(resultado);
        }

        [Fact]
        public void Deve_Retornar_Verdadeiro_Para_Uma_Idade_Igual_18()
        {
            var verificador = new Verificador();

            var resultado = verificador.EhMaiorDeIdade(18);

            Assert.True(resultado);
        }
    }

E rodando novamente a ferramenta temos:

100.00% │ Testing mutant 2 / 2 │ K 2 │ S 0 │ T 0 │ ~0m 00s │                                                       00:00:02                                                                                                                           
Killed:   2
Survived: 0
Timeout:  0

E na parte gráfica:

Conseguimos matar a mutação e assim produzindo um teste mais significante.
Espero que tenha gostado do texto e que tenha aprendido algo novo. Qualquer dúvida, leia a documentação. Até o próximo texto.

dotnet counters tool

Inácio Bueno — Fri, 28 Mar 2025 17:09:18 +0000

A ferramenta dotnet-counters tem como objetivo monitorar a saúde de aplicações no .net. Majoritariamente utilizada para consumir valores disponibilizados pela eventCounter api, que, por sua vez,fornece valores como uso de cpu, número de exceções, e informações do uso de memória.
Você pode instalar essa ferramenta com:

dotnet tool install --global dotnet-counters

Uso básico

Lista os processos que podem ser monitorados

dotnet-counters ps

aqui tive o retorno (eu criei uma console application com o nome de gc e deixei sendo executada):

350686  dotnet                     /usr/lib/dotnet/dotnet     dotnet gc.dll

Essa primeira coluna nos fornece o id do processo: 350686. Com esse id podemos seguir para o próximo passo:

Monitor

dotnet-counters monitor -p 350686

temos com retorno:

Collect

O collect monitora os contadores e exporta para um arquivo. Aqui nesse comando eu pedi para monitorar o mesmo processo anterior e pedi para o resultado ser exportado em json.

dotnet-counters collect -p 350686 --format json -o dados.json

resultado:

UI

E para finalizar eu gostaria de trazer uma ferramenta com uma forma de visualização mais amigável. E essa é a https://github.com/kkokosa/dotnet-counters-ui

Com essa ferramente temos basicamente as mesmas opções, mas agora podemos ver em gráficos:

Podemos reunir em um mesmo gráficos vários contadores:

Mas, por questões de escala, eu recomendo colocar informações diferentes em gráficos diferentes:

i18n e ASP.NET Core Web API

Inácio Bueno — Thu, 28 Nov 2024 21:07:49 +0000

i18n é uma abreviação para internacionalização, um processo que visa tornar um software adaptável a diferentes idiomas e culturas, sem a necessidade de grandes reestruturações. Em outras palavras, é preparar um software para ser utilizado em qualquer parte do mundo. A i18n envolve a separação do texto do código, a formatação de datas, números e moedas de acordo com cada cultura, e o suporte a diferentes conjuntos de caracteres. Ao internacionalizar um software, você amplia seu alcance, melhora a experiência do usuário e aumenta sua competitividade no mercado global.
Neste post irei te ensinar como iniciar o processo de internacionalização em um projeto webapi .net 8. Tenho aqui um projeto recém iniciado que usarei como exemplo e deixarei o link do github caso queira conferir o código.
A primeira coisa que devemos fazer é adicionar o serviço de localização na aplicação:

builder.Services.AddLocalization();
.
.
.
//Declaramos um array de culturas suportadas
var supportedCultures = new [] {"en-US", "pt-BR"};


// Especificamos as opções para o RequestLocalizationMiddleware
var localizationOptions = new RequestLocalizationOptions()
    .SetDefaultCulture("pt-BR")
    .AddSupportedCultures(supportedCultures)
    .AddSupportedUICultures(supportedCultures);


// Adiciona o RequestLocalizationMiddleware para definir automaticamente as 
// informações de cultura para solicitações com base nas informações 
//fornecidas pelo cliente.
app.UseRequestLocalization(localizationOptions);

(**Um detalhe importante que é ressaltado na documentação é que: "O middleware de localização precisa ser configurado antes de qualquer middleware que possa verificar a cultura de solicitação (por exemplo, app.UseMvcWithDefaultRoute())." Então preste atenção na ordem que vc está configurando os componentes do middleware.)

Agora iremos adicionar os recursos necessários para fazer as traduções. Irei criar um projeto classlib chamado Common, adicioná-lo na solução e referenciá-lo no projeto da api (estou usando dotnet cli, mas fique à vontade para utilizar uma ide se preferir):

dotnet new classlib -n Common
dotnet sln add Common/
dotnet add Api/Api.csproj reference Common/Common.csproj

Dentro do projeto Common criamos um diretório chamado "Resources" e nele criaremos dois arquivos de recurso. A estrutura fica assim:

Podemos começar a criar nosso primeiro texto para ser traduzido:

O item (1) é chave (2) e (3) são os valores que serão utilizados conforme o idioma requisitado.
Mas antes clique em propriedades do recurso, adicione Public nesse campo (custom tool):

E também altere a classe Resource para ter seu modificador de acesso para Public

public class Resource {...}

Na controller iremo injetar o IStringLocalizer que vem de Microsoft.Extensions.Localization. E o Resource é o que criamos então faça também o using de Common.Resources;

using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Localization;
using Common.Resources;

namespace Api.Controllers;

[ApiController]
[Route("[controller]")]
public class WeatherForecastController : ControllerBase
{
    private readonly IStringLocalizer<Resource> _localizer;

    public WeatherForecastController(IStringLocalizer<Resource> localizer)
    {
        _localizer = localizer;
    }

    [HttpGet(Name = "GetWeatherForecast")]
    public IActionResult Get()
    {
        return Ok($"Sucesso na traducao: {_localizer["msg_sucesso"]}");
    }
}

O uso do _localizer fica assim: _localizer["chave"].
Para testar nossa aplicação utilizaremos o postman:

E em inglês temos:

E quando não colocamos nada, permanece aquele que configuramos como padrão:

E isso é tudo, pessoal! Fiquem à vontade para comentar qualquer equívoco ou sugestão. Espero que tenha te ajudado!

What is a chicken? An introduction to distroless containers

Inácio Bueno — Wed, 30 Oct 2024 06:57:55 +0000

I’d like to begin this article with a well known story amongst philosophers students, it goes something like: “When Plato gave Socrates' definition of man as "featherless bipeds" and was much praised for the definition, Diogenes plucked a chicken and brought it into Plato's Academy, saying, "Behold! I've brought you a man."”

Asking google what is a container, we get the following definition coming from docker (https://www.docker.com/resources/what-container/): “A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings”. I don’t think it’s a bad definition, but we know that there are a lot of chickens in it.

And now the big question from this article: What is needed to run an application? Let’s go to the terminal:

So, I ran a container, specifically the aspnet runtime 8, listed some directories inside, used a command to write from 1 to 10, and then check the size of etc/; if you’re following along, you already know what I’m about to ask you: Why can I do all of those things? And you might say “I don’t know I have ADHD, I was already on instagram/tiktok sending videos to my friends; I got lost in the story of the guy who took a chicken to do who knows what ”. Fair point, I could say, but focus! And about the answer, in fact, I don’t know, maybe the ms team was just lazy and don’t really care for what they left there as long as your application runs it’s all fine. And if you’re so worried, do something yourself!
Bash once again:

Ok, we know where the binary of ls is, so just remove it, test if the application can still run without it and then add a line in our Dockerfile like RUN rm bin/ls. All done! Now you just need to remove all the other useless stuff. Life is beautiful and simple, I don’t get why so many people complain about it. But wait…. What other useless stuff? Can you remove ‘/’? Then you copy your application there and see what works. Right? YES! That's just the thing to do, in fact, do not even test it, do it directly in production. Say to your manager “devops is just a fancy word for easy work, let me handle it”.

Distroless is what we are looking for: a container image that contains only the necessary to run the application AND NOTHING BEYOND THAT. It’s a hard job to do this, google did it first to run Golang applications, and nowadays there are other options to choose from.
Here, let’s try do the same we did with the aspnet runtime container, but now a distroless:

Did you notice something? We couldn’t even get into the container, and if you are wondering, maybe it is zsh, ash, or sh… But no, we do not have a terminal in this container. If you look into chainguard description for the image cgr.dev/chainguard/aspnet-runtime:latest, you won’t find a terminal listed in the packages, neither you’ll find ls, seq, du…

“But why do all of this work? Our company is doing fine without it”. The main reason: Security. Each package opens a door and it’s not a door to a good place. Let’s see some basic security analysis from these images.
I’ve created 3 versions of the same dockerfile change only the images:

1.0 is the default image, 3.0 slim version and the 2.0 it’s distroless. (The first noticeable thing is the size, quite smaller. A big image does not mean that it’s bad, as may have heard, the implicit connection is that if your image is big then it contains more packages and thus it may introduce more vulnerabilities. But it’s not always the case.)
Security analysis results using two different tools to analyze them:
Default:

1.0: Total: 78 (UNKNOWN: 0, LOW: 60, MEDIUM: 16, HIGH: 1, CRITICAL: 1)
1.0: 24 vulnerabilities found in 13 packages

Slim:

3.0: Total: 78 (UNKNOWN: 0, LOW: 60, MEDIUM: 16, HIGH: 1, CRITICAL: 1)
3.0: Detected 13 vulnerable packages with a total of 24 vulnerabilities

Distroless:

2.0: Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)
2.0: No vulnerable packages detected

I hope with article you have learned something new, if you have any question message me on linkedin: https://www.linkedin.com/in/inacio88