Testing

Um teste para place_order precisa de um gateway de pagamento, um cliente de SMS e uma calculadora de impostos. Use os de verdade e cada execução do teste cobra um cartão e manda um SMS para um número de telefone real. Um teste unitário tem que rodar em milissegundos e sem rede, então os três precisam ser substituídos por outra coisa. Esse “outra coisa” vem em cinco tipos, cada um resolvendo um problema diferente, e tratá-los como intercambiáveis é por isso que as discussões de “só usa um mock” em code review não terminam nunca. ...

Um teste escrito depois do código tende a verificar o que o código faz, não o que ele deveria fazer. O desenvolvimento guiado por testes (TDD) resolve isso invertendo a ordem: você escreve o teste, vê ele falhar, e então escreve o menor código possível que o faz passar. Como o teste existe antes do código que ele verifica, ele não pode confirmar silenciosamente o que quer que o código retorne. Kent Beck formalizou esse ciclo como red, green, refactor em seu livro de 2002 Test-Driven Development: By Example. O nome pegou. ...

Uma função pode ter 100% de cobertura de testes unitários e a página que a chama ainda assim pode retornar um 500 em produção. Isso não é uma contradição. Testes unitários, de integração e end-to-end verificam coisas diferentes, e uma suíte forte em um e fraca em outro tem um buraco específico e previsível. O que cada tipo de teste verifica: unitário, integração e end-to-end Pegue uma funcionalidade de cadastro: uma função valida a entrada, grava uma linha em um banco de dados e envia um email de boas-vindas. Três testes podem cobrir isso, e cada um responde a uma pergunta diferente. ...