Oi Quero contar como os testes
funcionam no projeto
Autotech , um serviço de inspeção de automóveis da VIN. Sob o corte - sobre quais ferramentas usamos para testar requisitos, planejamento de sprint, como o processo de teste em nosso projeto funciona.
MindMap para tarefas de limpeza
Usamos scrum no Auto Center, pois essa é a metodologia mais bem-sucedida para nossas tarefas. Semanalmente, realizamos reuniões nas quais priorizamos, determinamos a complexidade, decompomos tarefas de backlog e definimos Definição de Pronto e Definição de Concluído para cada tarefa (você pode ler sobre elas
neste maravilhoso artigo ). Esse processo é chamado de preparação da lista de pendências.
Para uma limpeza eficaz, todas as dependências devem ser consideradas. Saiba como a implementação da tarefa pode afetar negativamente o projeto. Entenda qual funcionalidade você precisa oferecer suporte e qual cortar. Talvez, no processo de implementação da tarefa, a API para parceiros possa sofrer, ou você só precise se lembrar de implementar métricas pelas quais possa entender a eficiência dos negócios. Com o desenvolvimento de qualquer projeto, existem cada vez mais essas dependências, e considerá-las está se tornando cada vez mais difícil. Isso é ruim: é importante que a equipe de suporte descubra todos os recursos com o tempo. E, às vezes, as inovações precisam ser coordenadas com o departamento de marketing.
Como resultado, propus uma solução baseada no MindMap, que refletia quase todas as dependências que poderiam afetar o DoD, o DoR e a avaliação de tarefas.
A vantagem dessa abordagem é uma representação visual de todas as dependências possíveis em um estilo hierárquico, além de bolos adicionais na forma de ícones, seleção de texto e ramificações multicoloridas. Toda a equipe tem acesso a este MindMap, que permite manter o mapa atualizado. Espalho o espaço em branco desse cartão, que pode ser considerado um marco aqui -
melão . (Farei uma reserva imediatamente de que isso é apenas uma diretriz e é muito duvidoso usar esse cartão para suas tarefas sem finalizar o projeto.)
Análise de código estático e linear para Go
Em nosso projeto, um número bastante grande de código golang e, para que o estilo do código atendesse a certos padrões, foi decidido aplicar a análise estática de código. Sobre o que é, há um excelente
artigo sobre Habré.
Queríamos integrar o analisador ao processo de IC, para que a cada construção do projeto o analisador iniciasse e, dependendo dos resultados da verificação, a construção continuasse ou falhasse com erros. Em geral, usar o gometalinter como uma etapa de compilação separada no Teamcity seria uma boa solução, mas a visualização de erros nos logs de compilação não é muito conveniente.
Continuamos a pesquisar e encontrar o Linty Bot, desenvolvido como parte do hackathon Avito
por Artemy
Flaker Ryabinkov.
Este é um bot que monitora o código do projeto em nosso sistema de controle de versão e inicia um analisador de código diff a cada solicitação pull. Se ocorrer um erro durante a análise, o bot envia um comentário para este PR para a linha de código desejada. Suas vantagens são a velocidade de conexão com o projeto, a velocidade do trabalho, comentários sobre solicitações pull e o uso do popular Gometalinter linter, que por padrão já contém todas as verificações necessárias.
MockServer e como obter serviços para dar o que eles precisam
A próxima seção é sobre estabilidade de teste. Os revendedores de carros são extremamente dependentes das fontes de dados (eles vêm de revendedores, serviços governamentais, estações de serviço, companhias de seguros e outros parceiros), mas sua inoperabilidade não pode ser a base para se recusar a realizar testes.
Devemos verificar a montagem de relatórios nas fontes de trabalho e em sua inoperabilidade. Até recentemente, usamos fontes de dados reais no ambiente de desenvolvimento e, consequentemente, dependiam de seu estado. Verificou-se que verificamos indiretamente essas fontes nos testes de interface do usuário. Como resultado, eles tiveram testes instáveis que caíram junto com as fontes e aguardaram um levantamento das fontes de dados, o que não contribuiu para a velocidade de aprovação nos testes automáticos.
Tive a ideia de escrever meu próprio mock e, assim, substituir as fontes da Autotech. Mas, no final, foi encontrada uma solução mais simples - o
MockServer pronto, desenvolvimento de código aberto em Java.
O princípio do seu trabalho:
- criando expectativas
- corresponder solicitações recebidas,
- se uma correspondência for encontrada - envie uma resposta.
Um exemplo de criação de uma espera usando um cliente java:
new MockServerClient("localhost", 1080) .when( request() .withMethod("POST") .withPath("/login") .withBody("{username: 'foo', password: 'bar'}") ) .respond( response() .withStatusCode(302) .withCookie( "sessionId", "2By8LOhBmaW5nZXJwcmludCIlMDAzMW" ) .withHeader( "Location", "https://www.mock-server.com" ) );
Como você pode ver no exemplo, descrevemos a solicitação que enviaremos e a resposta que queremos receber. O MockServer recebe a solicitação, tenta compará-la com as que foram criadas e, se houver correspondências, retorna uma resposta. Se a solicitação não falhar, obteremos 404.
Para o MockServer, existem clientes para Java e JavaScript, excelente documentação e exemplos de uso. Existe a possibilidade de corresponder solicitações no RegExp, registro detalhado no servidor e um monte de chips. Para nossas necessidades, era um candidato ideal. O processo de inicialização é descrito em detalhes no site, portanto, recontá-lo aqui não entende o ponto. No único momento, a versão mais recente teve bastante memória vazada, por isso usamos a versão 5.2.3. Tome cuidado. Outro ponto negativo é que o Mockserver não possui suporte SOAP pronto para uso.
No momento, o MockServer trabalha conosco há cerca de três meses. Como resultado, a estabilidade dos testes, a velocidade de sua execução e a capacidade de receber dados em um ambiente de desenvolvimento aumentaram. E, consequentemente, há mais oportunidades para testes.
Epílogo
Essas tecnologias são as principais coisas que eu gostaria de falar neste artigo. Caso contrário, usamos as ferramentas de teste usuais: testes de API com o pacote Kotlin + JUnit + RestAssured, Postman para a conveniência de acessar a API. Neste artigo de revisão, não falei sobre nossa abordagem aos testes de interface do usuário. Usamos MBT e
graphwalker . Estamos planejando preparar uma postagem com colegas sobre isso.
Se você tiver alguma dúvida, pergunte nos comentários, vou tentar responder. Espero que este artigo seja útil para equipes de desenvolvimento. (A propósito, enquanto ela estava se preparando para o lançamento, um trabalho de
desenvolvedor de controle de qualidade apareceu em nossa equipe, mostrando aos interessados).