7 pecados que você não deve cometer em um teste técnico

7 pecados que você não deve cometer em um teste técnico

William Sena

Publicado por William Sena

05 Maio, 2019Leia em 3 minutos

1. Falha na execução

Tenha em mente que seu teste pode ser avaliado por mais de um desenvolvedor e estes podem não ter o tempo disponível e a paciência para rodar seu teste, caso seja uma aplicação de configuração complexa.

Neste exato momento entra o KISS (Keep It Simple Stupid), chega de floricultura, não adicione configurações complexas e inúmeras dependências externas ao projeto para tarefas simples. Há algum tempo atrás quando eu trabalhava com Visual Studio era comum encontrar projetos que só compilavam na máquina do criador, pois existiam dependências referenciadas pelo caminho absoluto e esses problemas normalmente aconteciam quando o criador estava de férias.

Na entrega de um teste técnico, devemos pensar como um Deploy em produção, não pode ocorrer a famosa desculpa funciona na minha máquina. O avaliador ficará muito feliz caso encontre um Dockerfile ou Docker-compose para iniciar o teste. Entregar um teste técnico que funciona facilmente é demonstrar que você está apto ao trabalho em equipe.

No teste opte por linguagens cross-platform, vale lembrar que seu código precisa rodar em qualquer máquina, somente entregue para uma plataforma específica caso esteja claro a utilização da plataforma na vaga / teste.

2. Entrega sem testes

Criar testes é indiscutivelmente uma boa prática e traz benefícios quando é bem aplicada, sendo assim entregar sem testes é perder pontos em sua avaliação, é deixar o avaliador crer que esse é o seu modelo de trabalho. Sinceramente alguém gosta de testar em produção? Simular o fluxo completo com fraca documentação? Por este motivo comece a escrever testes agora, para garantir e cobrir os cenários propostos.

3. Complexidade o famoso "over-engineering"

Quem nunca viu aquele padrão de arquitetura e saiu criando todos seu projetos seguindo a mesma abordagem? Atire a primeira pedra.

É muito comum surgirem padrões de arquitetura que se tornam tendências, muito cuidado nem todo padrão de arquitetura é adequado para qualquer aplicação.

Nem sempre é fácil detectar a utilização de uma bazuca para matar uma formiga, pois você pode se enganar com o discurso "Está verboso, mas ficou bem coeso, vai que um dia precisa modificar", Saiba que esse dia pode nunca chegar, pois aplicações nascem e morrem com uma certa frequência quando TI não é somente o meio do processo e realmente faz a diferença na receita da empresa.

Na minha opinião mantenha seu código limpo e tenha alta coesão em cada linha de código, método, classe e arquivos.

4. Padrões inexistentes

Já encontrei projetos com nomenclaturas DDD Service, Application, Repository, Domain e etc..., mas o projeto não seguia os princípios, se tratava de um três camadas vestido de DDD, sendo assim isso induz ao avaliador a crer que não há domínio do padrão adotado, visto aos equívocos cometidos.

Cuidado utilize padrões coerentes e que você tenha um certo domínio para não parecer que você está usando um nome pelo hype, como criar classes com nome de Ator e dizer meu projeto segue Actor Model, pronto falei rs.

5. Documentação mínima

Quem nunca criou um repositório e esqueceu de atualizar o README ou nem mesmo criou? Entenda que é muito importante documentar como instalar? como testar? como executar?

Aposto que todos adoram ler o getting start de um projeto, sabe porquê? Tudo funciona. Então porque isso tem que ser diferente no seu teste?

6. Requisitos incoerentes

Há requisitos imprescindíveis que devem ser garantidos em um teste, por exemplo quando há um teste de algoritmo existem valores de entrada "inputs" e resultados "output", o requisito mínimo é garantir que seu algoritmo tenha o resultado esperado. Ouvi uma frase que traduz um processo simples e o resultado esperado "Nesta máquina entra porco e sai linguiça".

Em testes de aplicação podem existir requisitos como um framework, biblioteca, banco de dados, até mesmo linguagem. Então se a exigência é aptidão em Angular não entregue em React apenas pelo hype, ou Vue se o requisito é React.

Lembre-se que é um requisito no qual você trabalhará, mesmo não sendo melhores amigos. É muito comum achar que o teste é momento de mostrar o todos os dons, até mesmo os recentemente adquiridos. É bom demonstrar isso porém sem esquecer dos requisitos, tenha em mente, será que essa decoração atrapalha na performance? traz baixa a coesão? aumenta a complexidade? As pequenas escolhas vão influenciar na decisão do avaliador.

7. Mantenha o teste atualizado

Entregar o teste em uma versão antiga somente é aceito caso seja um requisito. Por exemplo, em frameworks e bibliotecas com bastante popularidade e concorrência é comum ter mudanças até breaking changes, o Angular passou por diversas modificações mesmo depois da versão release. Atualmente a cada mudança de código você é obrigado a escolher entre estabilidade ou evolução. Sendo assim tire já instruções obsoletas do seu teste.

Desafio! Escreva um hello world com seu framework favorito aguarde cerca de 3 meses ou semanas e tente atualizar a versão e veja muita coisa quebrando.

Conclusão

Essa lista aborda itens importantes e avaliados em testes técnicos, sim já entreguei testes sem alguns destes requisitos no passado, por este motivo se um dos itens fizer você pensar a respeito, meu objetivo foi alcançado.

Inscreva-se em nossa lista

E receba por email novos conteúdos.