Melhor resposta
Atualmente estou trabalhando para a AutoTrader, que faz isso muito bem, na minha opinião.
Nós apenas sentamos você na frente de um laptop, com um monitor e teclado / mouse maiores, pareando com um de nossos desenvolvedores sênior e observados por um desenvolvedor sênior diferente.
É muito divertido para todo mundo, tirando os nervos habituais da entrevista, e o fato de que você está conhecendo novas pessoas. Mas certamente, quando sou seu par, tento manter um relacionamento amigável, fazer você se sentir bem-vindo e assim por diante. Como eu normalmente faria. Na verdade, estou torcendo para que você tenha sucesso.
Você recebe uma descrição do problema de meia página de uma tarefa simples. E então você faz um pouco de programação em pares.
Existem várias coisas observadas e pontuadas:
- Você escreve os testes primeiro? Depois do código? Nunca?
- Você usa testes para pensar sobre o design?
- Você nomeia as coisas com clareza?
- Você favorece OOP, programação procedural – ou apenas um função enorme?
- Você interage bem com o par? Ou mesmo?
- Você explica seu pensamento à medida que avança e convida a dupla a contribuir? Ou sentar em silêncio?
- Você usa recursos padrão em Java, como coleções? Se não, o que você faz?
- Você usa bem o IDE (que é de sua escolha)?
- Você divide bem o problema? Mal? Nem um pouco?
Se você pode fazer Java, TDD e / ou design para serem testados em unidades, e parece um tipo razoavelmente pessoal, você tende a obter uma pontuação alta.
Este teste não é sobre conhecimento de recursos de linguagem estranha, ou conhecimento de algoritmo estranho, ou até mesmo para resolver o problema.
É tudo para ver como você usa essas coisas que escreveu em seu currículo na vida real.
Você vai realmente gostar. Isso dá a todos uma imagem justa de onde um candidato está.
Também elimina impiedosamente as alegações falsas de currículos.
Digamos que você faça TDD? Não sabe o que afirmar significa? Oh céus. Digamos que você domina o OOP? Todo o código, que não funciona, está no mesmo método do teste de unidade que fornecemos? Nossa.
(E sim, isso realmente aconteceu).
Para mim, foi uma grande surpresa estar em ambos os lados desse processo.
Resposta
TDD é uma ferramenta. O que há de errado é tratar o TDD como uma religião.
O TDD é normalmente feito com testes de unidade: testes de pequenas partes ou funções (“unidades” ) do seu código. Os testes de unidade devem ser executados rápido , então você geralmente simula quaisquer dependências de serviço externo e apenas garante que o próprio código está sendo testado.
O enorme elefante na sala com isso é que às vezes os serviços externos que você simulou contêm a maior parte da lógica de uma função. Se a sua “unidade” pegar um item de um banco de dados usando uma consulta e o retornar, zombando que a interação é 100\% inútil exceto como um substituto para a verificação de tipo.
Deixe-me dizer novamente de uma maneira diferente: Os chamados “líderes de pensamento ”Que pregam o evangelho de TDD também pregam frequentemente o evangelho de linguagens dinâmicas. Então, as línguas que eles estão dizendo a você são muito mais produtivas na verdade, exigem muito mais trabalho para testar e, muitas vezes, para reescrever esses testes quando precisar refatorar.
Escreva seu código em uma linguagem mais segura como C #, Java ou TypeScript, e você não Não preciso me preocupar em verificar se os tipos ainda são válidos. E há toneladas de benefícios reais em usar linguagens de tipo estático, além de não precisar escrever testes que não testam realmente nada.
Então, o que realmente quero dizer com os testes “não testam nada”? Digamos que você tenha uma função que faça uma consulta SQL em seu banco de dados. Ele deve procurar itens filtrados por um determinado campo. Para escrever um teste de unidade rápido, você simula a consulta SQL. A menos que sua biblioteca fictícia possa simular toda a lógica do PostgreSQL trabalhando em um conjunto de dados de amostra, a lógica real de sua função não está sendo testada ; os únicos testes substantivos que você poderia escrever para verificar a lógica só validariam se seus simulações estavam retornando respostas adequadas.
Eu freqüentemente vejo simulações que simplesmente “verifique se o banco de dados foi chamado o número certo de vezes”. Afinal, isso daria a você 100\% de cobertura de código! Ótimo, um número para impressionar os gerentes não técnicos que não significa absolutamente nada na prática! Estatísticas enganosas da equipe Go!
Não, o que você precisa é de testes de sistema, ou testes de integração / E2E, para validar que todo o seu sistema está trabalhando. Não apenas testes de unidade, mas testes que não simulam as chamadas para o banco de dados, mas, em vez disso, realizam essas chamadas.E quando um conjunto de testes precisa erguer um banco de dados de teste real, limpando-o e propagando-o entre os testes, isso torna o TDD uma prática impraticável; é muito lento.
Então vá em frente e escreva o código primeiro e, em seguida, escreva seu teste E2E e verifique se ele está obtendo o resultado correto. Caramba, você pode usar o recurso de instantâneo de suítes de teste como Jesthttps: //jestjs.io/docs/en/snapshot-testing para apenas validar que a resposta não muda; olhe uma vez para ter certeza de que está correto e, depois que você disser a Jest que está certo, ele validará se permanece o mesmo em execuções futuras! As APIs podem ser testadas e ter seus testes atualizados de maneira quase automatizada!
Portanto, se você ignorar os delírios dos fiéis do TDD, poderá fazer seu trabalho duas vezes mais rápido porque não precisa esperar 10 minutos (ou mais! Eu vi um conjunto de testes que levou mais de uma hora…) para que o conjunto E2E completo fosse executado para ver o teste falhar antes de começar a escrever seu código.
Além disso, testar a IU em tudo , conforme apontado na resposta de Moray Taylor, é impraticável em muitas circunstâncias. Existe algum nível de teste E2E que pode ser aplicado à IU, mas na maioria das vezes o retorno do investimento raramente parece valer a pena para o caso geral.
Dito isso, eu estava trabalhando em uma biblioteca de gráficos uma vez que estava sendo usada por mais de cem videogames diferentes e escrevi um teste E2E suite para validar que uma mudança na lógica interna da biblioteca não quebraria algum jogo obscuro que eu nunca tinha visto. Bibliotecas sempre merecem testes mais completos. Mas, para a IU de um único aplicativo, o teste E2E quase nunca faz sentido em minha experiência.