10 pontos essenciais para testes técnicos

Teste técnico

Este artigo apresenta os principais pontos que podem afetar a qualidade dos testes técnicos.

1.  Linguagem

Hoje, as empresas que usam apenas uma linguagem estão extintas. Eu mesmo trabalho com uma variedade de linguagens com diferentes frequências de uso e contexto, incluindo JavaScript/TypeScript, Ruby, Python, Elixir, Lua e Scala/Java.

Desde de a era mainframe 🦖, onde COBOL, BASIC e CLIPPER escreviam arquivos e armazenavam em bancos de dados, podemos dizer que já trabalhávamos com duas linguagens, a stack era formada por SQL + alguma linguagem de programação.

Novos contextos e linguagens foram introduzidos e surgiram aplicações desktop, web e mobile, aumentando a variedade de linguagens usadas.

Entretanto mesmo com essa variedade eramos reféns do servidores HTTP, havia perguntas como?

Como hospedar uma aplicação node no IIS? O apache suporta uma aplicação Rails?

Os serviços de hospedagem ainda existem, e essas questões ainda existem nesse contexto, mas graças aos containers e à evolução de como os aplicações são hospedadas e mantidas, esses problemas se tornaram menos importantes e não afetam mais as escolhas de linguagem de programação. Podemos dizer que os container impulsionaram essa variedade de linguagens.

De volta ao conteúdo, a escolha da linguagem define sua entrega. Algumas empresas exigem a entrega do teste ténico em uma stack específica. Já vesti essa capa algumas vezes e consegui entregar o teste, tive uma semana bem movimentada. Tenho um perfil generalista, e posso garantir que apenas a vivência com uma linguagem pode melhorar a produtividade e refinar sua entrega. A entrega foi feita, mas certamente poderia ter sido melhor em uma linguagem com qual tenho maior vivência.

Não recomendaria usar uma linguagem apenas para causar uma boa impressão em uma entrevista. Se a linguagem não é um pré-requisito, recomendo escolher uma linguagem que faça você escrever um código de alto nível. Erros, quem nunca? Eles existem independentemente da linguagem, porém quanto maior o domínio da linguagem, menor o risco de erros conceituais.

2. Testes

Criar testes é uma prática de longe obrigatória, quando você escreve seu código e produz testes ao mesmo tempo sua produtividade aumenta e muito! Mas sei que como programador temos a tendência de sair escrevendo código e depois testar, pela simples ansiedade de ver tudo funcionando, "quick and dirty" 🤪. Independente da forma como você cria seus testes eles devem cobrir todas as unidades da sua aplicação, todos os cenários e se possível todos os comportamentos.

Ufa! No meu contexto de desenvolvedor, os cartões perfurados não serão descartados quando o teste falha e muito menos peças ou matéria prima. Nós, desenvolvedores, temos o privilégio de testar todas as coisas de forma virtualizada, mas é inevitável que alguns problemas ocorram em produção. Até hoje não encontrei nenhum 😇 anjo programador, que escreva códigos com zero problemas em produção, porém a experiência ajuda a mitigar problemas, o "fail fast", seja com feature flag, teste A/B ou rollback rápido.

3. Complexidade "over-engineering"

Sei que não é fácil identificar excessos arquitetônicos. Pois caímos em falácias como:  "Ficou verboso, porém muito coeso" ou "Vai facilitar futuras refatorações". Ouvi uma frase que faz muito sentido:

Devemos evitar o reuso antes do uso

Produzir códigos somente pensando no reuso você pode facilmente encontrar níveis complexos, inúmeras interfaces de marcação e módulos com uma única função. Os sintomas tendem a piorar dependendo da mentalidade da equipe.

O tema excesso de abstração me faz lembrar de um momento da minha carreira em que utilizei um "framework" adquirido pela Empresa X para implementar um worker que lia uma fila. Este framework possuía diversas classes e interfaces para implementação de workers que processam mensagens em filas, pois foram criadas várias abstrações para permitir a leitura de filas, arquivos, bancos de dados, ftp, etc... boa ideia! No entanto, a natureza imperativa do framework com abstrações desnecessárias levou a um aumento considerável no desenvolvimento de um worker que apenas lê filas, graças ao viés "talvez eu precise ler uma pasta ou FTP algum dia".

Devemos sempre revisitar códigos que escrevemos. As vezes olho para meus códigos e penso: "Uau, por que você fez isso!" Resumindo, não sobrecarregue seu código com arquitetura e conceitos hypados. O código escrito por programadores deve ser limpo e claro em todos os níveis. O que está claro para você pode não estar claro para sua equipe. Somente revisões de código podem nos ajudar a encontrar esse equilíbrio.

4. Padrões

Entre nós programadores, temos muitas sopas de letrinhas, (DDD, BDD, CQRS, SOLID, etc.). Gostaria de compartilhar uma experiência que tive, já avaliei testes onde as classes que utilizavam a nomenclatura DDD (aplicativo, repositório, domínio, etc.) não seguiam os princípio. Boom! Ficou claro que alguém estava tentando usar algo para impressionar e isso acontece com certa frequência.

Resumindo, ao escolher um modelo arquitetônico, certifique-se de seguir os princípios. Seu repositório não é um controlador, seu serviço não é um repositório e assim por diante.

5. Execução

É importante que seus testes sejam executados sem problemas. Recentemente, tenho tido problemas com pacotes Ruby (gem) que não funcionam devido a incompatibilidade entre os pacotes do sistema operacional. Os containers podem resolver esse tipo de problema de incompatibilidade com o sistema operacional e evitar o famoso "funciona na minha máquina". Entregar os testes usando containers podem facilitar a execução e avalição do seu teste técnico.

Escrevi alguns artigos sobre Docker, segue uma introdução.

Criando o seu primeiro Docker Container

Docker é uma plataforma de código aberto que permite aos desenvolvedores criar, publicar e executar facilmente aplicativos de forma isolada.

William SenaWilliam Sena

6. Documentação

O tema é polêmico e o Manifesto Ágil afirma sucintamente: "software em funcionamento mais que documentação", mas isso não significa que a documentação deva ser abolida no seu projeto. Não queremos documentações padrão PMBOK, mas é importante ter um README em nosso repositório e um diagrama de negócios ou técnico com explicações na WIKI.

Existe algum programador que não goste daquela documentação básica para executar um projeto?

7. Requisitos incoerentes

Existem requisitos básicos que devem ser assegurados por testes. Se for um teste algorítmico, existe um valor de entrada "input" e um resultado "output". O requisito mínimo é garantir que o algoritmo forneça os resultados esperados. Já ouvi uma frase que se traduz bem o que deve ser feito. "Esta máquina, entra o porco 🐖 e sai a linguiça 🌭".

Existem requisitos específicos para framework, bibliotecas, banco de dados e até mesmo linguagens. Portanto, não entregue em React, se requisito for Angular ou Vue, acredite já recebi um teste em Vue e foi solicitado React 😕.

Lembre-se, é um requisito que você deve cumprir, mesmo que não seja seu melhor amigo. É bom demonstrar apetidões no teste, mas não se esqueça de manter seus requisitos em mente. Essa decoração afeta o desempenho? Isso atrapalha a coesão? Adiciona mais complexidade? Pequenas decisões podem influenciam as decisões dos avaliadores.

8. Teste atualizado

Certifique-se de que os artefatos usados ​​em seus testes estejam atualizados corretamente. Hoje, as releases nascem a cada minuto e nem sempre conseguimos acompanhar. Pode ser que você use uma versão que foi obsoleta meses ou dias atrás, ou um recurso de linguagem que não é considerado uma boa prática pela comunidade. Ao adicionar referências a testes, verifique se o pacote está atualizado, quais são as alternativas, quantas pessoas estão envolvidas e quem está por trás do pacote.

9. Prazo

Não espere até o último minuto para terminar o teste técnico. Porque provavelmente você acabará criando algo de baixa qualidade que não se encaixa na sua forma de trabalhar. E o mais importante é cumprir a data de entrega acordada.

10. Perguntas! Esteja preparado

A preparação para uma entrevista de emprego é uma tarefa essencial, precisamos considerar todos os prós e contras da solução aplicada para não nos surpreender ou passar uma impressão errada do nosso trabalho.

Lembre-se de que as opiniões dos testes são isoladas e podem não refletir seu modo de trabalhar. Muitas vezes as pessoas avaliam a entrega sem considerar alguns pontos.

• Nível de vaga (estágio, júnior, pleno e sênior);
• O tempo de experiência nos requisitos exigidos;
• Prazo de entrega do teste;

Conclusão

Este é um guia para ajudá-lo a concluir seu teste técnico. Nós, programadores, sabemos que os requisitos estão aumentando constantemente. Antes de enviar seu teste, use ferramentas úteis como formatadores, linters e verificadores que melhoram a qualidade do código.

Mesmo depois de seguir essas e outras dicas e entregando o seu melhor. Você pode obter resultados negativos, mas não se preocupe, fique em paz. Não deixe que o "feedback" individual de um entrevistador dite sua carreira ou o desencoraje a continuar. Esteja preparado para muitos "nãos"!

Deus abençoe seu kernel 🧠!