Lady{de}bug – Lady{de}bug

Linux Básico

Mon, 01 Dec 2025 00:00:00 +0000

Minhas anotações sobre o básicos do Linux

Configurando o SonarQube Localmente

Sat, 20 Sep 2025 00:00:00 +0000

Isso não é um tutorial, é mais para o entendimento e estudo sobre a ferramenta e como aplicar ela em projetos pequenos, até médio porte, em repositórios fechados (código privado). Bom, como eu já tinha o SonarQube instalado na minha máquina, abaixo segue como configurar o Docker.

Opção 1: Remover o container existente

Para um trabalho de Pós-graduação eu tinha configurado para um projeto de estudo de análise de código, neste caso foi reconfigurar para outro projeto (depois eu configuro novamente correto para o projeto de estudo de análise de código).

docker rm sonarqube

Agora posso executar o comando para subir um novo container:

docker run -d --name sonarqube -p 9000:9000 sonarqube:lts-community

Sim, a versão é gratuíta, para aprendizado antes de sair pagando algo que não sabe usar.

Opção 2: Substituir o container automaticamente

Se quiser forçar a substituição, use o parâmetro –rm (remove ao parar) ou –replace (caso use Podman). No Docker, geralmente removemos manualmente como acima.

Opção 3: Verificar o status do container

docker start sonarqube

Para encerrar use o comando:

docker stop sonarqube

Executar o SonarQube localmente

Agora a parte que interessa é configurar localmente o SonarQube, e fazer um escaneamento básico.

Primeiro um setup de configuração (acho que vale adicionar isso no script de desenvolvimento).

1. Pré-requisitos

Java 11 ou superior instalado na máquina (SonarQube precisa do Java para rodar).
Docker (opcional, mas facilita a execução do SonarQube — realmente).

2. Baixando e rodando o SonarQube

Link de download: https://www.sonarsource.com/open-source-editions/sonarqube-community-edition/

Aqui a primeira parte de ajustar o docker então precisa se atentar a deixar ele executando, corretamente, sem problemas.

docker run -d --name sonarqube -p 9000:9000 sonarqube:lts-community

Pronto! SonarQube rodando localmente.

Ajuste as configurações de senha e segue para a página:

Configuração do SonarQube

Acesse http://localhost:9000
Login padrão:
- Usuário: admin
- Senha: admin

Agora vamos configurar para fazer um escaneamento do projeto

Gerando um Token de autenticação

No menu superior direito, clique no seu usuário > My Account > Security.
Em “Generate Tokens”, crie um novo token (ex: nome-projeto-token).
Guarde esse token (será usado no scanner).

Instalando o SonarScanner

O SonarScanner é o CLI para enviar seu código ao SonarQube. Ou seja, localmente via terminal vamos falar para ele ler o projeto e então temos a análise.

Instalação via NPM (para projetos Node):

npm install -g sonarqube-scanner

Para referências de cada projeto segue: https://docs.sonarsource.com/sonarqube-server/analyzing-source-code/scanners/sonarscanner

Configurando o SonarScanner no Projeto

Na raiz do projeto, crie um arquivo chamado sonar-project.properties:

Exemplo:

sonar.projectKey=nome-projeto
sonar.projectName=Nome-projeto
sonar.projectVersion=1.0
sonar.sources=.
sonar.language=js,php
sonar.sourceEncoding=UTF-8
sonar.host.url=http://localhost:9000
sonar.login=SEU_TOKEN_AQUI

Problemas encontrados

ERROR: You’re not authorized to run analysis. Please contact the project administrator.

O que significa esse erro?

O SonarScanner está tentando enviar os resultados da análise para o SonarQube, mas o usuário (ou token) configurado não tem permissão para realizar essa operação no projeto configurado no SonarQube.

Perfeito! Vamos ver o que fiz de errado: o nome do projeto no arquivo sonar-project.properties não estava igual ao que eu configurei no SonarQube local.

Agora pronto: quando executar o comando sonar-scanner vai executar o escaneamento no projeto e seguida mostrar em tela os resultados.

Cypress e Boas Práticas de Automação

Thu, 24 Oct 2024 13:07:00 -0300

Evitando o uso de Falsos Positivos com Cypress. Segue abaixo um exemplo de um código, e um arquivo commands com um simples login na aplicação:

Essa aplicação estava ocorrendo um certo erro ao realizar o login, e foi adicionado o seguinte trecho de código na automação para poder realizar o login com sucesso:

Mas o que esse trecho diz? Serve para suprimir os erros que ocorrem na aplicação durante a execução dos testes do Cypress.

Como assim? Ao usar cy.on('uncaught:exception') e retornar false, está instruindo o Cypress a ignorar qualquer erro que ocorra na sua aplicação. Isso permite que o teste continue mesmo que a página ainda não esteja totalmente carregada, dando tempo para que os elementos sejam renderizados antes que o Cypress tente interagir com eles.

Por que remover cy.on('uncaught:exception') é importante? Nesse caso, como está sendo manipulado o teste, forçando a “ignorar esse erro retornando que ele seja falso” é adicionado um falso positivo no nosso teste. Segue abaixo:

Alternativas e soluções para lidar com o tempo de carregamento e evitar adicionar “falso positivo”

Em vez de suprimir erros, deve-se usar as ferramentas do Cypress para garantir que os elementos estejam presentes e prontos para interação antes de tentar acessá-los. Algumas opções incluem:

cy.wait(): Aguarde um determinado tempo ou até que um elemento ou condição específica seja atendida antes de prosseguir com o teste.

OBS: cuide as más práticas ao usar o comando cy.wait(número) , leia a documentação sobre Anti-Pattern.

Unnecessary Waiting aqui

Em vez disso, use:

cy.intercept('GET', '/users', [{ name: 'Maggy' }, { name: 'Joan' }]).as('getUsers')
cy.get('[data-testid="fetch-users"]').click()
cy.wait('@getUsers') // <--- wait explicitly for this route to finish

cy.get(...).should('exist') ou

cy.get(...).should('be.visible')

Precisa garantir de que o elemento existe e está visível na página antes de tentar interagir com ele.