Resumo. _No contexto do desenvolvimento de software em métodos ágeis, ter um feedback rápido e contínuo é crucial para o sucesso dos projetos. Uma das formas de garantir a detecção rápida de bugs é através da execução de testes automatizados. Dado o alto valor dos testes automatizados, é necessário avaliar os vários frameworks disponíveis no mercado atualmente para determinar qual deles melhor se adequa às necessidades do projeto. Neste trabalho, é proposta uma análise comparativa entre três frameworks de testes: Selenium, uma das ferramentas de automação mais tradicionais; Cypress, uma ferramenta que ganhou bastante popularidade nos últimos anos; e Playwright, uma ferramenta mais recente que tem atraído bastante atenção. Para realizar essa análise, foram desenvolvidas suítes de testes automatizados para uma aplicação web, com o objetivo de comparar os scripts gerados com base em critérios selecionados. De
This novel workaround simply hides any command log entries that originate from fetch/XHR requests.
While I've updated this receipe for Cypress 10 and converted it to TypeScript you should be able to use it in a JavaScript project by ignoring the cypress.d.ts file and placing the snippet from e2e.ts in e2e.js instead.
| /// <reference types="cypress" /> | |
| // *********************************************************** | |
| // This example plugins/index.js can be used to load plugins | |
| // | |
| // You can change the location of this file or turn off loading | |
| // the plugins file with the 'pluginsFile' configuration option. | |
| // | |
| // You can read more here: | |
| // https://on.cypress.io/plugins-guide | |
| // *********************************************************** |
| [alias] | |
| ci = commit | |
| co = checkout | |
| cm = checkout master | |
| cb = checkout -b | |
| st = status -sb | |
| sf = show --name-only | |
| lg = log --pretty=format:'%Cred%h%Creset %C(bold)%cr%Creset %Cgreen<%an>%Creset %s' --max-count=30 | |
| incoming = !(git fetch --quiet && git log --pretty=format:'%C(yellow)%h %C(white)- %C(red)%an %C(white)- %C(cyan)%d%Creset %s %C(white)- %ar%Creset' ..@{u}) | |
| outgoing = !(git fetch --quiet && git log --pretty=format:'%C(yellow)%h %C(white)- %C(red)%an %C(white)- %C(cyan)%d%Creset %s %C(white)- %ar%Creset' @{u}..) |
Hoje um colaborador da lista sobre Teste de Software [DFTestes] (http://br.groups.yahoo.com/group/DFTestes/) perguntou em uma thread sobre PhantomJS qual era a difernça entre Smoke Test e Acceptance Test. Ai resolvi responder. Como a lista é somente de acesso aos usuários registrados, estou colocando um resumo, na minha ótica, a diferença entre eles:
Dentro de um contexto ágil nós temos uma separação clara do que é smoke test e o que é teste de aceitação.
-
Smoke Test: conjunto de testes (bem menor do que o conjunto de teste de aceitaçaõ, que vai configurar posteriormente em uma regressão) com o intuito de validar se os pontos maisimportantes da aplicação continuam funcionando após as alterações.
-
Teste de Aceitação: São os testes funcionais que conhecemos. Em um contexto ágil eles são chamados de aceitação ao invés de funcional, pela ótica que adotamos a estes testes, que vão tanto validar a aplicação funcionalmente como validar também da ótica de um usuário (fazer uma venda completa, por exemplo). Este