Forem: Paulo Gonçalves

Teste de mutação 👽: O que é e como fica a cobertura de código?

Paulo Gonçalves — Wed, 19 Aug 2020 03:53:36 +0000

Sumário

Who tests the tests?
Porque cobertura de código não é confiável
Testes de mutação
- Detalhe da execução
- RIP Cobertura de código?
- Desvantagem
- Adoção em grandes projetos - Case Google
Verificando na prática
- Cobertura de código
- Teste de mutação
Fontes

Esse conteúdo foi apresentado com mais detalhes e profundidade na live do AT Talks em 25/11/20. Para assistir clique aqui.

Who tests the tests?

Quando pensamos em validar a eficiência dos testes implementados, normalmente o que vem à mente é a métrica de cobertura de código. Porém, será que ela realmente é a melhor prática para garantir que os testes estão realmente testando os cenários possíveis?

Cobertura de código é uma métrica que valida o quanto do código foi coberto pelos testes.
Ou seja, verifica quais linhas do código foram executadas ao rodar os testes e retorna o percentual de cobertura.

Leia esse conteúdo (en) e esse (pt-br) para saber mais.

Utilizando apenas a métrica de quantidade de cobertura de código não conseguimos garantir que todos os cenários foram cobertos, apenas... quais linhas foram executadas 😮.

Pense um pouco sobre isso. Alguma vez já viu um teste sem asserção apenas para aumentar a cobertura de código? Tenho certeza que já soube de uma situação parecida.

Claro que nessa situação, para evitarmos engraçadinhos, basta colocarmos alguma biblioteca que valida que todos os testes possuem asserção e que o percentual de cobertura de código está acima de algum número mágico, como 80%.

O problema é que, como dito, a cobertura de código não valida a eficiência dos testes, e vamos ver abaixo o porquê.

Porque cobertura de código não é confiável

Abaixo temos um pequeno método que possui apenas 1 teste validando o seu comportamento.

Disclaimer
É perceptível que esse método possui mais de 1 cenário, porém precisamos de exemplo prático e simples para comparar cobertura de código e teste de mutação.

// ./src/cnh.js
module.exports = podeTirarCarteiraDeMotorista = idade => {
  return idade >= 18
}

// ./__tests__/cnh.spec.js
test('Deve retornar false para pessoa com menos de 18 anos', () => {
  expect(podeTirarCarteiraDeMotorista(17)).toBe(false)
})

Se verificarmos a cobertura de código do arquivo cnh.js, será apresentado que ele foi 100% coberto (aqui o gestor comemora), porém sabemos, por ser um teste simples, que a validação não está eficiente e que poderíamos validar outros cenários, como:

Deve retornar true se idade for igual a 18
Deve retornar true se idade for igual a 19

Cobertura de código de `cnh.js`:

E é baseado nessa brecha da métrica de linhas executadas é que o uso do teste de mutação faz sentido.

"...100% code coverage score only means that all lines were exercised at least once, but it says nothing about tests accuracy or use-cases completeness, and that’s why mutation testing matters"
Baeldung, 2018

Testes de mutação

Imagine um sanduíche coberto com uma pasta. Cobertura de código vai te dizer que o pão está 80% coberto com pasta. O teste de mutação, por outro lado, vai dizer que a pasta é chocolate e não... bem... qualquer outra coisa.

O conceito de teste de mutação é bem simples:

Bugs, ou mutantes, são inseridos no código e os testes são executados em cima do código mutado. Se pelo menos 1 dos testes quebrar ou tiver timeout, o mutante é considerado morto 💀 e aquele trecho de código alterado é considerado como coberto pelos testes.

Ainda não está claro? Então vamos lá.

Abaixo está o nosso código original:

// ./src/cnh.js
const podeTirarCarteiraDeMotorista = idade => {
  return idade >= 18
}

O teste de mutação irá detectar todos os pontos que podem ser alterados no código e atuar em cima deles. No nosso exemplo serão feitas as seguintes alterações (serão 5 mutantes no total):

A expressão condicional idade >= 18 será alterada para true e false;
O operador de idade >= será alterado para < e >;
O bloco => { return idade >= 18 } será alterado para => {}.

Quer entender tudo que será mutado no seu código e para o que será mutado? Leia 'Mutantes suportados pelo stryker (en)'.

A cada alteração feita, todos os testes criados são executados. Se algum teste quebrar, significa que aquela alteração (mutação) está coberta, então ela foi assassinada.

É um pouco confuso a questão de que para que aquela mutação seja considerada como morta (sucesso) é preciso que algum teste quebre (afinal, teste quebrar é ruim). Porém temos que entender que o nosso teste foi feito para o cenário ABC e se o cenário foi alterado para ABZ, o nosso teste tem que detectar essa mudança e falhar.

O teste de mutação é nada mais e nada menos do que automatizar todo o processo de "sabotar o código e executar testes para ver se eles falham"

Se executarmos teste de mutação utilizando o teste e código apresentados anteriormente, o resultado seria esse:

Tínhamos 100% de cobertura de código, porém o teste de mutação revelou que 2 mutações criadas não resultaram em quebra do nosso teste (sobreviventes), demonstrando que há brecha no nosso teste.

Para que todos os 5 mutantes não sobrevivam, precisamos criar um novo teste que cubra essa brecha, como:

test('Deve retornar true para pessoa maior de 18 anos', () => {
  expect(podeTirarCarteiraDeMotorista(18)).toBe(true)
})

Detalhe da execução

Quando executamos o teste de mutação são feitas as seguintes etapas:

Analisa quais arquivos serão mutados;
- No nosso caso foi cnh.js.
Executa todos os testes e espera que todos passem;
- O teste é abortado se algum teste falhar. Para validar se algum teste quebrou com mutação é imprescindível que todos os testes sejam executados com sucesso com o código original.
Gera mutante para todos os trechos de código;
- No nosso caso foram 5 mutantes criados.
Executa todos os testes para cada mutante gerado;
A pontuação final do teste é de acordo com a quantidade de mutantes que foram mortos ou resultaram em timeout em comparação com a quantidade total de mutantes.

RIP Cobertura de código?

Embora teste de mutação seja uma métrica muito interessante para entendermos a saúde dos testes criados, é importante salientar que ele NÃO substitui a cobertura de código, atuando apenas como complemento e possui algumas desvantagens que impedem fortemente a sua adoção em larga escala.

Portanto, cobertura de código continuará sendo uma métrica bastante usada e não é uma ferramenta antagonista ao teste de mutação

Desvantagem

Como o teste de mutação analisa todos os possíveis pontos que podem ser mutados no código e executa todos os testes para cada mutação, ele possui uma execução que onera bastante a máquina e possui um alto tempo de execução.

Devido à necessidade de ter um alto poder computacional, o uso do teste de mutação chega a ser proibitivo em projetos médios e grandes.

Um exemplo dessa limitação é o projeto ServeRest. Todos os 86 testes existentes são executados em aproximadamente 550 milissegundos, enquanto os testes de mutação atuam em cima de 22 arquivos, resultando em 599 mutantes e com execução média de 19 minutos.

No nosso código de exemplo a cobertura de código é executada em 9 ms enquanto o teste de mutação é executado em 3 segundos.

Adoção em grandes projetos - Case Google

A seção Adoção em grandes projetos - Case Google será atualizado com os detalhes das estratégias de testes de mutação em breve. Esses detalhes foram apresentados na live do AT Talks.

Essa limitação de poder computacional não impediu a adoção do teste de mutação pela Google nos seus códigos (que possuía 2 bilhões de linhas em 2018), porém ela teve que utilizar de algumas estratégias de criação da mutação.

Traditional mutation analysis is computationally prohibitive which hinders its adoption as an industry standard. In order to alleviate the computational issues, we present a diff-based probabilistic approach to mutation analysis that drastically reduces the number of mutants by omitting lines of code without statement coverage and lines that are determined to be uninteresting - we dub these arid lines.
State of Mutation Testing at Google

No bom português:

A análise de mutação tradicional é computacionalmente proibitiva, o que impede sua adoção como um padrão da indústria. A fim de aliviar os problemas computacionais, apresentamos uma abordagem probabilística baseada em diff para análise de mutação que reduz drasticamente o número de mutantes, omitindo linhas de código sem cobertura de instrução e linhas que são determinadas como desinteressantes - dublamos essas linhas áridas.
Estado do teste de mutação na Google

Para entender a fundo a estratégia adotada por essa companhia, leia a publicação de pesquisa sobre o estado do teste de mutação na Google, feita para a ocasião da 40ª Conferência Internacional de Engenharia de Software.

Verificando na prática

Para executar a cobertura de código e teste de mutação citados nesse texto, primeiramente clone esse repositório, executando:

git clone https://github.com/PauloGoncalvesBH/teste-de-mutacao.git

Instale as dependências com o comando npm install.

Testes

O teste foi implementado utilizando jest. Para rodar os testes execute:

npm test

Cobertura de código

Para rodar a cobertura de código, execute:

npm run test:coverage

Teste de mutação

O teste de mutação é executado com a biblioteca stryker e com o runner do stryker para jest. Para rodar o teste de mutação execute:

npm run test:mutation

Desafio

O que acha de aumentar o score do teste de mutação de 60% para 100%?

Crie novo teste no arquivo cnh.spec.js que mate 👿 as 2 mutações que estão sobrevivendo e mantenha a cobertura de código em 100%.

Fontes

Os seguintes materiais forneceram conteúdo e base para a criação desse texto:

Esse post está sendo versionado e hospedado no Github

Pare de usar git push --force

Paulo Gonçalves — Wed, 12 Aug 2020 20:01:05 +0000

Esse conteúdo é abordado no meu treinamento de conceitos de git

Reescrevendo a história da branch com segurança

Ao reescrever a história da nossa branch, com git rebase, por exemplo, costumamos utilizar o git push --force. Essa opção força o envio das alterações e substitui todas as alterações remotas pela versão local.

O grande perigo é que, se outra pessoa tiver enviado uma alteração no repositório remoto e que não estava na sua versão local, esse trabalho será totalmente perdido.

`git push --force-with-lease`

Para evitar essa situação (e muita dor de cabeça), adote o uso de git push --force-with-lease em detrimento de git push --force.

Esta opção permite forçar o push sem o risco de sobrescrever acidentalmente o trabalho de outra pessoa.

Ele atualizará a branch remota APENAS se o histórico dela for igual ao histórico que você alterou localmente, caso contrário o push será rejeitado. Nesse caso, você terá que levar a alteração remota da outra pessoa para a sua branch local antes de tentar fazer o git push --force-with-lease novamente.

Exemplo de push rejeitado com o alerta de stale info (informação velha):

Pronto 😃 agora você pode garantir que não irá apagar acidentalmente alteração que alguém possa ter dado push enquanto você reescreveu o histórico!

Para aprofundar no tema recomendo a própria documentação do git sobre git-push.

Don't rewrite public history unless you're really sure about what you're doing. And if you do, be safe and force-with-lease.

Esse post está sendo versionado e hospedado no Github

Aprenda conceitos de git, não comandos

Paulo Gonçalves — Tue, 14 Jul 2020 23:34:46 +0000

Liquid syntax error: Unknown tag 'endraw'

Entrega contínua no ServeRest 🚀

Paulo Gonçalves — Mon, 08 Jun 2020 01:46:00 +0000

Sumário

❓ O que é entrega contínua (Continuous delivery)?
❓ O que é o ServeRest?
🏁 Resultado
🔨 Desafios
📁 Libs NPM utilizadas
📑 Fluxo de trabalho
- 1️⃣ Issue
- 2️⃣ Desenvolvimento local
- 3️⃣ Pull Request
- 4️⃣ Criação da release
- 5️⃣ Comunicação de release gerada

Nesse texto vou relatar todas as etapas necessárias para a implementação da entrega contínua no ServeRest, as vantagens dela e porque não é apenas inserir npm publish na pipeline do projeto, mas sendo um conjunto de boas práticas.

Não é possível entregar código de qualidade sem um bom processo de desenvolvimento

⛔ O QUE NÃO IREI ABORDAR: Detalhes de implementação o suficiente para configurar a entrega contínua no seu projeto. Porém é possível utilizar as informações passadas para tal fim, já que é um agregado de informações coletadas e que deram certo.

Antes de abordarmos a entrega contínua aplicada no ServeRest, temos que entender 2 coisas:

❓ O que é entrega contínua (Continuous delivery)?

A definição de entrega contínua fornecida pelo http://continuousdelivery.com é:

Entrega Contínua é a capacidade de obter alterações de todos os tipos - incluindo novos recursos, alterações de configuração, correções de bugs e experimentos - em produção ou nas mãos dos usuários, com segurança e rapidez, de maneira sustentável.

❓ O que é o ServeRest?

O ServeRest é um projeto NPM open source de ensino de testes de API para QAs. Ele fornece APIs Rest de forma fácil e bem documentada para que seja possível testar os verbos GET, POST, DELETE e PUT, autenticação e segurança de API.

Sendo o ServeRest um projeto com foco em qualidade, não seria menos esperado dele de que possuísse um processo de desenvolvimento de qualidade.

🏁 Resultado

Antes de passarmos por detalhes da entrega contínua, é importante entendermos o ganho adquirido.

A entrega contínua foi importante para garantir a qualidade de software do ServeRest e rapidez na entrega de novas releases. Com ela apenas código bem estruturado, que passa em todos os testes e possui boa mensagem de commit é integrado ao código. Além de que as releases são geradas apenas se necessário, de acordo com alguns critérios.

Para o mantenedor do projeto, basta realizar code review em PR de outros colaboradores e realizar o merge com a branch master ou beta. Não terá mais a preocupação em atualizar a master/beta local, criar tag, atualizar o changelog, commitar, executar git push e npm publish apontando para a tag correta (@latest caso fosse a branch master e @beta caso fosse a branch beta).

O impacto para o usuário é de que correções sejam liberadas de forma mais rápida e, principalmente, bugs em produção são menos frequentes.

🔨 Desafios

Para entregar o código em produção com rapidez e segurança, alguns itens teriam que ser solucionados:

Todos os cenários deveriam ser cobertos por teste;
O código deveria seguir o padrão do JS;
As mensagens de commit deveriam seguir o padrão do Conventional Commit;
Todas as alterações que geraram release deveriam estar documentadas no Changelog;
O versionamento deveria corresponder às alterações desde a última release e ao Semantic versioning;
A estratégia de branches deveria permitir integrar código na master e beta apenas se todas as validações fossem executadas;
Publicar na dist-tag @latest apenas o que fosse integrado na master, e @beta o que fosse integrado na branch beta;
Somente deveria ser feita publicação automática caso a alteração realizada necessitasse de publicação.

📁 Libs NPM utilizadas

Para solucionar todos os desafios listados acima e poder entregar uma release com qualidade e manter o código bem estruturado, foram utilizadas diversas libs NPM em conjunto, cada qual com sua responsabilidade e sendo executadas em etapas diferentes no fluxo de trabalho.

Standard - JavaScript style guide, linter, and formatter;
Husky - Executa ações em git hooks, como pre-commit e commit-msg;
Commitlint - Valida se a mensagem de commit segue o conventional commits;
Supertest - Testes de APIs Rest;
Semantic-release/commit-analyzer - Analisa as mensagens de commit de acordo com o conventional-changelog e informa qual tipo de versão deve ser gerada (major, minor ou patch);
Semantic-release/release-notes-generator - Gera as notas da release;
Semantic-release/changelog - Gera/atualiza o changelog com as notas da release;
Semantic-release/npm - Atualiza a versão do projeto e publica o pacote NPM;
Semantic-release/git - Commita o package.json, package-lock.json e o CHANGELOG.md;
Semantic-release/github - Publica uma release no Github com as notas da release.

Para mais detalhes visualize a seção devDependencies do package.json

📑 Fluxo de trabalho

Abaixo será relatado todo o fluxo de trabalho, desde o momento que um bug é relatado até o momento que a correção está publicada em nova release.

1️⃣ Issue

Um usuário abre uma nova issue no projeto, relatando um bug e seguindo o template de issue.

2️⃣ Desenvolvimento local

Libs: husky, commitlint e standard.

O desenvolvedor irá atuar em uma branch a partir da master (seguindo o Github Flow).
Serão feito os ajustes afim de corrigir o bug, e então será realizado o commit. Nesse momento será utilizado a lib husky.
1. pre-commit: Será executado o standard, validando se o código respeita ao padrão de código do JS.
2. commit-msg: Será executado o commitlint, validando se a mensagem de commit segue o conventional commit.

Caso alguma validação encontre problema, o commit será abortado, e então o dev terá que ajustar o código ou a mensagem de commit. Com isso todo commit realizado estará bem estruturado.

3️⃣ Pull Request

Libs: supertest, commitlint e standard

O desenvolvedor irá abrir no Github uma Pull Request para integrar a sua branch com a master. O PR somente será mergeado caso as seguintes etapas sejam aprovadas:

Code review de outro desenvolvedor;
Validação dos testes de API criados com supertest nas 3 principais versões LTS do node. Executado na pipeline de integração contínua;
Validação da mensagem de commit com commitlint. Executado na pipeline de integração contínua;
Validação da estrutura do código com standard. Executado na pipeline de integração contínua.

Print de validações feitas em um Pull Request:

4️⃣ Criação da release

Lib: semantic-release/*

Após o PR ser aprovado e integrado com a master ou beta, começa todo o processo de entrega contínua.

Inicialmente são executados as mesmas validações feitas na PR (commitlint, standard e testes de API). Apenas com a execução com sucesso de todas essas validações é que é iniciado o processo de entrega contínua.

Print da pipeline de Continuous Delivery:

Na atividade release é executado o semantic-release, que utiliza a configuração implementada e realiza as tarefas de entrega contínua.

Inicialmente é validado se há commit, desde a última git tag, que gera uma nova release major, minor ou patch. Caso esse critério seja atendido as seguintes ações são realizadas:

A versão do package.json e do package-lock.json são atualizadas;
É gerada as notas de release contendo informação de todos os commits desde a última git tag;
O CHANGELOG é atualizado com as notas de release;
É realizado publicação no NPM, e o artefato é armazenado temporariamente;
package.json, package-lock.json e CHANGELOG são commitados com nova tag e informação da nova release. É utilizado o usuário semantic-release-bot;
É criado nova release no Github utilizando a tag gerada, o artefato armazenado temporariamente e as notas de release;
É feita comunicação aos interessados sobre a nova release. Veja mais na seção Comunicação de release gerada.

Print do commit do semantic-release:

Print da release gerada no github:

Caso queira verificar com mais detalhes a configuração feita quanto ao semantic-release, verifique o arquivo .releaserc.js e o workflow de continuous delivery (a partir da linha 60).

5️⃣ Comunicação de release gerada

Lib: semantic-release

Após a publicação da release em produção é preciso comunicar aos interessados de que suas respectivas issues e PR foram corrigidas.

O semantic-release verifica quais issues foram fechadas e quais PRs foram aprovados e que fazem parte da nova release. Com isso ele adiciona comentário informando de que uma nova release está disponível com a solução para a situação relatada e adiciona as labels released on @{tag} e released on @{versão}.

Print de comentário e label automático em PR:

Com isso passamos por todas as etapas da entrega contínua no contexto do ServeRest. Caso tenha dúvidas ou sugestões, deixe um comentário abaixo. Não deixe de visitar o repositório do ServeRest e deixar a sua estrelinha ⭐.

Esse post está sendo versionado e hospedado no Github

QA, trate sua automação como software

Paulo Gonçalves — Tue, 19 Nov 2019 04:58:11 +0000

Quando pensamos em automação de testes, muitas vezes passa pela nossa cabeça questões como pirâmide de testes e qual linguagem/framework será utilizado para realizar a automação. Caso seja levado em conta boas práticas de automação, não passamos da discussão de adotar page objects ou page actions na automação de interface.

Porém, é importante atentarmos que há muitos outros fatores determinantes para a manutenção daquela automação por membros da equipe, afinal, quem nunca trocou trechos de código via chat ou teve dificuldade para saber porque que uma determinada alteração foi realizada na automação?

É importante preocuparmos mais com o nosso código, afinal...

Código de teste é software e deve ser tratado como tal

E vamos ser sinceros, assim como o dev deve entregar seu código com qualidade, nada mais justo que nós, QA, também entreguemos com qualidade.

Esses problemas foram solucionados há muito tempo no desenvolvimento de software e pretendo listar aqui algumas dicas interessantes de serem adotadas no seu ~~código de automação~~ software.

Resumo:

Utilize Git e deixe o código acessível
Escreva boas mensagens de commit (caso já utilize git)
Padronize o seu código
Documente o seu projeto
Separe as dependências de desenvolvimento e produção

Utilize Git e deixe o código acessível

Versione o seu código utilizando Git e o torne acessível para os outros membros através de conta no Gitlab, Github ou hospedado em servidor da empresa.
Com isso, pare de:

Hospedar o código apenas na sua máquina (ela pode pifar).
De manter código comentado, por ter medo de que aquele trecho de código será necessário um dia (nunca será).
E, principalmente, de enviar arquivos via e-mail e tendo sempre que fazer o controle de qual arquivo pode ser substituído ou não.

Deixe tudo isso para o git resolver.

Para saber mais, veja as dicas de git para testers.

Bônus:

Use branch.

Evite usar GitFlow. Para saber mais leia Git Flow vs Github Flow e GitFlow considered harmful.

Use rebase, evite de usar merge.

Escreva boas mensagens de commit (caso já utilize git)

Agora que está utilizando o git, é importante que não cometa as falhas de escrita de mensagens de commit.
É comum clonarmos um repositório de testes, tentarmos investigar porque tal arquivo foi modificado e depararmos com um log nada amigável como esse:

Sim, esse log é real

Vendo esse log, consegue identificar de forma fácil o motivo de cada alteração? Para saber terá que investigar as alterações realizadas ou conversar com o autor do código, que pode nem estar mais na empresa. E tudo isso vai te fazer gastar um bom tempo.

É importante que as mensagens de commit sejam totalmente claras, de forma de que ao lê-la fique claro que tipo de alteração foi feita e o que levou ela a ser feita, como essa:

Consegue notar que esse commit consegue passar mais informações importantes, poupando tempo de investigação?

Para entender sobre como escrever boas mensagens de commit, leia o guia de mensagens de commit e convenção de commit.

Bônus:

Use git-cz para te ajudar a escrever mensagens de commit usando a convenção.

Valide se a mensagem está respeitando o padrão no pre-commit, conciliando, por exemplo, commitlint e husky.

Padronize o seu código

Como cada pessoa possui o seu estilo de codificar, é esperado de que o projeto de automação, por ter mais de 1 pessoa, possua vários estilos diferentes.

O código abaixo, escrito por 2 pessoas, possui as seguintes diferenças:

Espaçamento no início do código.
Uso de ponto-e-vírgula.
Uso de aspas duplas e aspas simples.

Para solucionar esse problema use um formatador de código opinativo, como o prettier, para garantir que todo o código esteja consistente e com um estilo único, facilitando sua leitura.

Bônus:
Execute o prettier no pre-commit com husky, para garantir que todo código enviado esteja padronizado.

Documente o seu projeto

É importante que o seu projeto possua uma boa documentação, pois é ela que vai informar para as outras pessoas sobre qual o papel do projeto, como configurar, executar, contribuir e outras informações importantes.

Código sem documentação é difícil de ser operado por pessoas alheias ao projeto, que terão que perder tempo analisando o código para entenderem um pouco sobre o mesmo.

Por isso, foque em escrever um README.md para o seu projeto. A extensão .md é de markdown, uma linguagem simples de marcação que apoia a escrever com boa produtividade textos organizados.

README.md é tão importante que todo projeto open source procura ter ele bem detalhado e atualizado.

Exemplo de markdown extraído do projeto open source protractor-helper

Para saber mais, veja esse ótimo tutorial de markdown.

Separe as dependências de desenvolvimento e produção

Essa dica serve apenas para javascript

Quando estiver instalando as dependências necessárias para o seu projeto, é importante identificar quais são necessárias apenas para desenvolvimento e quais são para a execução dos testes.

Essa separação é importante para quando outra pessoa ou o ambiente de CI for rodar a sua automação, ele baixe apenas as dependências necessárias. Afinal, para rodar os testes não é importante baixar o pacote de validação de commit.
É preciso ter em mente também de que algumas dependências possuem dezenas de dependências, fazendo com que, de forma fácil, seja baixado mais de 100 pacotes de forma desnecessária.

Exemplo de separação

Nessa situação, quando for fazer a instalação apenas para executar a automação, utilize:

npm install --production

Para saber mais, leia a documentação do package.json e do npm-install.

Se chegou até aqui, não deixa de fornecer feedback e curtir o post 😃

Gostou do assunto e quer saber mais? Leia Por favor, “don't code like a tester” um ótimo post do Leonardo Galani e de onde tirei a frase 'Código de teste é software e deve ser tratado como tal'.

Forem: Paulo Gonçalves

Teste de mutação 👽: O que é e como fica a cobertura de código?

Sumário

Who tests the tests?

Porque cobertura de código não é confiável

Cobertura de código de cnh.js:

Testes de mutação

Detalhe da execução

RIP Cobertura de código?

Desvantagem

Adoção em grandes projetos - Case Google

Verificando na prática

Testes

Cobertura de código

Teste de mutação

Desafio

Fontes

Esse post está sendo versionado e hospedado no Github

Pare de usar git push --force

Reescrevendo a história da branch com segurança

git push --force-with-lease

Esse post está sendo versionado e hospedado no Github

Aprenda conceitos de git, não comandos

Entrega contínua no ServeRest 🚀

Sumário

❓ O que é entrega contínua (Continuous delivery)?

❓ O que é o ServeRest?

🏁 Resultado

🔨 Desafios

📁 Libs NPM utilizadas

📑 Fluxo de trabalho

1️⃣ Issue

2️⃣ Desenvolvimento local

3️⃣ Pull Request

4️⃣ Criação da release

5️⃣ Comunicação de release gerada

Esse post está sendo versionado e hospedado no Github

QA, trate sua automação como software

Código de teste é software e deve ser tratado como tal

Utilize Git e deixe o código acessível

Escreva boas mensagens de commit (caso já utilize git)

Padronize o seu código

Documente o seu projeto

Separe as dependências de desenvolvimento e produção

Cobertura de código de `cnh.js`:

`git push --force-with-lease`