Neste post, quero compartilhar uma revisão de 15 relatórios da conferência Heisenbug, para contar o que foi interessante nas estandes das empresas e também compartilhar material de vídeo do relatório da Artyom Eroshenko sobre a criação de plugins de ação para o IntelliJ IDEA que ajudarão a alterar rapidamente o código do projeto de teste.
Informações sobre o HeisenBug
Heisenbug - Conferência Técnica para Especialistas em Testes. É principalmente de interesse para testadores, engenheiros de desenvolvimento de software em teste e especialistas em testes automatizados e de carga. Os organizadores são a equipe
JUG.RU , atrás da qual são realizadas conferências como Joker, HolyJS, SmartData, DevOops, DotNext, Mobius.
Local de encontro
A quinta conferência foi realizada no hotel Slavyanskaya Radisson, estação de metrô Kievskaya, Moscou. Ao se aproximar do hotel, um banner eletrônico com o logotipo da conferência era visível. Além disso, na entrada do saguão do hotel, o participante era acompanhado de placas nas mesas de check-in e no guarda-roupa. É impossível se perder. O registro dos participantes e palestrantes ocorreu no térreo, no saguão principal da conferência havia estandes de parceiros, salas de conferências, salões com coffee break e almoços. O nível de guardas de segurança agradou, para que "coelhos clandestinos" não chegassem. No total, o evento contou com a participação de mais de 500 participantes, a maioria dos quais se registrou duas semanas antes do início.
O programa
O programa pode ser encontrado
aqui . Quero observar que o
JUG.RU sempre se esforça para tornar o programa prático, sem água extra e com conhecidos especialistas estrangeiros. Os relatórios são divididos em símbolos:
Se esta é a primeira vez que você planeja se tornar um palestrante na Heisenbag, consulte o
memorando do palestrante - ele contém muitas informações úteis.
Comunicação e voluntariado
Para que os participantes não perdessem algo importante na conferência, foram organizados um canal de telegrama e um bate-papo por telegrama. A propósito, no último, eles estavam procurando voluntários para assistir a vídeos, para os quais davam um ingresso de conferência gratuito.
Se você decidir se tornar um voluntário, indique sua decisão aos organizadores o mais cedo possível. A preparação para o evento é realizada muito antes da conferência. Sujeito à disponibilidade, você será designado à equipe.
Stands da empresa
Desta vez, a conferência contou com mais de uma dúzia de stands de grandes empresas de TI, como Deutsche Bank, Alfa-Bank, Raiffeisen, Badoo, Luxoft, SKB Kontur, Gett, etc. Cada uma das empresas abordou a organização de interações com os participantes do evento à sua maneira. , portanto, entre as performances não era preciso ficar entediado. Foi possível resolver problemas de uma pequena lembrança memorável, jogar vídeo e jogos de tabuleiro e participar da loteria.
Raiffeisen se ofereceu para fazer uma busca on-line com uma solução para todos os tipos de quebra-cabeças, também conhecedores de clássicos eternos que poderiam jogar Mortal Kombat 3 na Sega. Os colegas do Alfa-Bank fizeram um telegrama com tarefas, além de um grande conjunto de Lego Mindstorms na loteria. Quero elogiar o estande do Deutsche Bank, onde os desenvolvedores de comunicação ao vivo distribuíram tarefas e participaram da discussão, ao contrário de todos os outros estandes, onde apenas checaram as respostas.
Muitas empresas caçam discretamente especialistas, distribuindo folhetos descrevendo as vagas (nem todas iguais para se envolver em caridade).
Visão geral dos relatórios
1. Temos DevOps. Vamos demitir todos os testadores - Baruch Sadogursky.
A conferência foi aberta por Baruch Sadogursky, advogado de desenvolvedores do JFrog, um conhecido palestrante em conferências relacionadas a Java e Devops. No relatório, Baruch abordou os problemas de qualidade de software em face de lançamentos freqüentes, causados por demandas de negócios em constante crescimento, a complexidade do teste de código devido à arquitetura pobre e a modernização do papel do testador nas equipes modernas do Agile. Foi interessante ouvir o relatório do começo ao fim, muito humor, fatos interessantes e comparações.
Bem, as principais idéias do relatório podem ser colocadas em um slide, que ilustra que a automação de teste e as práticas de DevOps reduzem os custos de tempo dos processos de rotina e permitem que você dedique mais tempo à implementação de novas tarefas.
2. Precisa refatorar um projeto? Existe IDÉIA! - Artem Eroshenko.
Artyom, em seu relatório, falou sobre a criação de plug-ins de
ações para o IntelliJ IDEA, que o ajudarão a alterar rapidamente o código do projeto de teste.
Ele deu uma explicação das principais classes (AnAction, PsiClass, PsiAnnotation, AnActionEvent, JavaCodeStyleManager), que são o ponto de entrada das Ações de Plug-in.
Considerou como resolver as seguintes tarefas:
a) O que é automatizado no projeto e o que não é. Sincronização automática com Jira.
De acordo com o texto da anotação, @DisplayName foi para Jira, recebeu os tickets necessários e cancelou todas as conexões necessárias usando @TmsLink.
b) Afixe automaticamente @Tags no contexto do Jira.
Existem certos rótulos no
ticket de regressão favorito . Vamos para o teste, há anotações @TmsLink, usamos o plug-in e temos novas anotações @Tags e, com a ajuda do Junit, podemos executar testes nessas tags.
c) O que é verificado nos testes?
Há um autoteste, há etapas, exportamos e temos etapas nos testes. Também no vídeo, há um exemplo para dois testes.
Artyom também demonstrou como mudar rapidamente do Allure 1 para o Allure 2.
Um relatório muito prático para quem está pensando em otimizar o processo de escrever código. O código fonte dos plugins pode ser encontrado
aqui .
3. Projeto Java e Reactor? - Mas e os testes? - Kirill Merkushev.
Cyril compartilhou sua experiência no desenvolvimento da startup médica internacional Vivy. Ele contou como os problemas de escalabilidade de um sistema monolítico foram resolvidos usando microsserviços e a biblioteca do Reactor. Foi prestada muita atenção a essa biblioteca, seus princípios básicos, abordagens para testar sistemas reativos, recursos matadores (como pontos de verificação e logs na cadeia de solicitações, Hooks e solicitações repetidas (nova tentativa).
Pessoalmente, eu não lidei com o teste de sistemas reativos, então para mim era novo e interessante.
4. Conforme escrevemos a estrutura do Sealant para procurar vazamentos de memória em JS , Sergey Dokuchaev.
Esta palestra é sobre vazamentos de memória (objetos que são acessíveis a partir do código, mas não são mais necessários) em aplicativos da web de página única. Sergey definiu a tarefa para encontrar automaticamente todos os vazamentos críticos de memória na versão lançada do produto. Ele falou sobre as dificuldades de encontrar esses erros e como fazê-lo manualmente usando as ferramentas do Google Chrome. Em seguida, examinei a ferramenta
SeaLant , da qual ele é o autor. O SeaLant automatiza a detecção de vazamentos interagindo com o processo do Chrome usando o protocolo Chrome DevTools. O relatório terminou com o fato de que, se a página puder executar scripts cíclicos (de um dispositivo, com uma sessão, sem recarregar a página), provavelmente, ao testá-los, você poderá se livrar da maioria dos vazamentos de memória.
5. Recursos de teste visual de interfaces - Anton Usmansky, desenvolvedor líder de ferramentas Gemini (uma ferramenta de teste visual) e Hermione (uma ferramenta de última geração e de uso geral que pode executar asserções de captura de tela).
O relatório é útil para aqueles que estão pensando em implementar ferramentas de teste visual em seus projetos. Aqueles que já usam Gêmeos e Hermione também podem estar interessados - isso dá uma compreensão de como as ferramentas são organizadas por dentro. Em alguns lugares, o autor lida com coisas bastante básicas.
6. Problemas no Selenium WebDriver - Alexey Barantsev.
Alexey falou sobre os problemas do projeto Selenium e as razões de sua ocorrência. Ele compartilhou os detalhes do conjunto de repositório único usando o coletor
Bazel . Ele abordou o tema da visibilidade do elemento (no padrão W3C WebDriver não há operação que verifique se um elemento está visível ou não) e explicou como as funções getProperty, getDomAttriubute, getAttribute diferem.
Conhecer problemas permitirá que os usuários distinguam recursos de bugs e desenvolvam "muletas" eficazes em seus projetos de teste.
7. Receitas para criar do zero e o desenvolvimento de um sistema de teste de carga - Anatoly Plaskovsky.
Anatoly representa o grupo de pesquisa de desempenho Yandex.Money. Em seu relatório, ele compartilhou suas práticas sobre como determinar a necessidade de estudos de desempenho, onde encontrar pessoas para realizar essas atividades e como construir um processo de pesquisa. O autor se concentra no fato de que a pesquisa de desempenho! = Teste de carga e que apenas os testes de produção podem mostrar um resultado relevante. Ao mesmo tempo, é possível realizar experimentos sem problemas para os clientes, escolhendo rotas e dados de teste, monitorando e prevendo possíveis resultados do cenário.
A Anatoly criou uma área de carregamento de bate-papo por telegrama, que discute o teste de carga e onde você pode pedir ajuda e conselhos.
8. Falha épica dos fabricantes de dispositivos - Valentine Wylsacom Petukhov.
O primeiro dia foi encerrado pelo relatório do notório Wylsacom, que foi percebido ambiguamente pelo público (a julgar pelo bate-papo dos participantes do heisenbag no telegrama :)).
Para mim, não tirei nada de interessante do relatório sobre testes beta de dispositivos e aplicativos, mas talvez os fãs tenham gostado. A área de discussão estava alinhada para a foto, então o PR foi um sucesso.
9. Teste de integração elegante do zoológico de microsserviços usando TestContainers e JUnit 5 usando o exemplo da plataforma global de SMS - Andrey Markelov.
O autor contou como os microsserviços estão sendo testados em sua empresa usando o pacote TestContainers + Junit 5 + MockServer. O relatório parecia interessante, mas esse esquema não é para um grande número de microsserviços. Link para o
código fonte.
10. Voyeurismo do testador ou Como os usuários do monitoramento o ajudarão - Antonina Khisametdinova.
Um relatório muito interessante, embora mais relacionado ao design da web do que a testes. Ele fala sobre práticas e armadilhas de UX a serem evitadas ao projetar a interface do cliente.
Antonina identificou os principais erros ao observar usuários em soluções de interface do usuário, como desativar botões, usar carregadores, dicas de ferramentas, componentes familiares etc.
Também é importante notar o design gráfico do relatório com exemplos intuitivos de projetos reais (como convém aos relatórios sobre UX).
11. Testando sistemas com dependências externas: problemas, soluções, Mountebank - Andrey Glazkov.
O autor falou sobre a evolução das etapas de umedecimento em seus projetos. Considerados os prós e os contras de zombar no nível do código. Ele compartilhou sua experiência nos casos em que é bom criar uma implementação de serviço falsa. Mas se você deseja que serviços falsos sejam reconstruídos em tempo real, com proxy e ao mesmo tempo registros de solicitações recebidas, Andrey recomenda examinar mais de perto a ferramenta
Mountebank .
As principais vantagens:
- mounteBank - trabalha no nível TCP;
- Injeção de JavaScript;
- confiabilidade e velocidade imediata;
- excelente documentação;
- suporte à conteinerização do docker.
Limitações identificadas da ferramenta:
- sistemas externos com armazenamento de dados;
- WebSocket - não suportado;
- testes de carga (> 150 rps), mas você pode usar um balanceador.
12. Por que analisar testes de ponta a ponta de aplicativos móveis - Vyacheslav Frolov.
Em seu relatório, Vyacheslav falou sobre o status dos autotestes no Badoo, a saber, como eles resolveram o problema de paralelizar 1.500 testes de interface do usuário móvel, que levam 30 horas de máquina para rodar em um simulador. Como resultado, eles conseguiram alcançar um resultado de 30 minutos, o que lhes permitiu executar 80 mil testes por dia. Além de um aumento linear de energia, a otimização foi aplicada para limpar o cache do aplicativo em vez de reiniciar o simulador. Os criadores de perfil também foram mencionados no relatório e como foram usados para detectar casos especiais de gargalos nos testes: por exemplo, o método long_press () no ios 11.0 foi executado por 5 segundos e, após a otimização, começou a ser executado em um segundo, ou com a ajuda do cabeçalho http -alive ", você pode evitar o restabelecimento da conexão, acelerando significativamente todos os testes ao mesmo tempo. O autor também contou como exibir os resultados do criador de perfil usando as ferramentas FlameGraph e FlameChart.
13. Testes unitários: da teoria à prática - Vadim Pushtaev.
O autor compartilha sua experiência no desenvolvimento de UnitTests. O relatório consistiu em três partes.
- O que queremos da UT → Regressão (Alterado o código, verificado), Influência na arquitetura (Quando os desenvolvedores escrevem testes, o código melhora), Compreensão (para lidar com o código legado);
- Princípios → Vadim lembra que a teoria não é tão boa quanto a prática. Rejeitou o princípio de "testar a interface, não a implementação", pois pode haver muita lógica na implementação. Além disso, o princípio "testes de unidade não é um mecanismo de teste". Ele considera isso um tipo de técnica arquitetural, poderosa e muito útil, mas esse não é um mecanismo para verificar e corrigir o código.
- Implementação → Uma história sobre as técnicas que o autor usa no trabalho (para cada classe há uma classe de teste, a criação de seus próprios pares, o uso de dependências externas, se necessário, etc.).
14. Testando e chorando com o Spring Boot Test - Kirill Tolkachev
Cyril decidiu nos devolver ao mundo de IoC, DI e Spring e contar como escrever testes de unidade e componente usando o JUnit 5 e o SpringBoot.
Uma grande vantagem deste relatório é que o palestrante escreveu a maioria dos testes em tempo real, ou seja, demonstrou claramente o processo passo a passo dos testes de empacotamento com anotações do Spring. No entanto, devido à grande quantidade de código, foi difícil colocar todas as técnicas mostradas na minha cabeça. Cyril revisou os recursos do Spring para trabalhar com perfis, Mock & Spy Beans, além de definir configurações de contexto. Quanto a mim, o Spring é uma estrutura bastante pesada para essas tarefas e apenas usuários experientes poderão não entrar no rake ao desenvolver testes de unidade.
15. Nós realizamos
autotestes móveis - Ekaterina Bateeva.
No relatório, o autor examinou a ferramenta XCTest para automatizar aplicativos iOS. Duplicar essa ferramenta em outros projetos não era conveniente.
Ou seja, as seguintes desvantagens foram identificadas:
- difícil de ler as configurações de inicialização;
- difícil de configurar montagens;
- difícil de integrar com vários serviços;
- inconveniente para gerenciar capturas de tela;
- inconveniente para configurar as reinicializações de teste.
Em seguida, Catherine falou sobre a estrutura
Fastlane de código aberto, que resolveu seus problemas.
Sumário
Em geral, gostei da conferência. Recebeu uma carga de emoções e respostas a perguntas de interesse. Na sessão do BoF, a maioria dos participantes tirou suas “máscaras” e teve discussões acaloradas no âmbito dos tópicos do BoF. Coffee breaks e jantares eram perfeitos, sempre havia algo para comer. Também quero observar a organização do evento - a equipe do JUG.RU sempre torna o Heisenbug cada vez melhor. Finalmente - vá a conferências, compartilhe o conhecimento adquirido e melhore suas habilidades!
PS: Expresso gratidão a Alexei Rumyantsev por participar da preparação do artigo e a Artem Eroshenko pelo material em vídeo.