Pular para o conteúdo principal

TDD porque não usar

Acho muito estranho todos falarem sobre TDD hoje em dia. Mas pouco tem definido o que é e como utilizar no benefício do projeto. A mais ou menos uns 3 anos eu assisti uma palestra do Lucas Bastos, "Ágil como o MacGyver" e nela ele falava exatamente o mesmo. As pessoas se prendem em modelos prontos de solução e deixam de analisar o que realmente elas precisam.

Sendo assim resolvi comentar um pouco sobre minha experiência com TDD.

Para que fazer testes ?

Acho engraçado quando vejo algumas pessoas atribuindo os testes aos bugs. Fazer ou não fazer os testes não é solução para evitar bugs. Uma vez que mesmo seus testes podem conter bugs ou dificilmente eles vão ser tão geniais quanto os usuários de um sistema.

Os testes servem para garantir a continuidade do funcionamento do seu sistemas e não para remover erros. Em outras palavras, garantir qualidade.

Já vi programadores incríveis escreverem mais de 30 linhas de código e nem mesmo executar 1 vez se quer seu código parar verificar se ele realmente está funcionando ou não. Porém o código funcionou perfeitamente, porque o programador nesse caso, tinha o domínio total do problema e sabia exatamente onde e como resolver o problema. E da mesma forma já vi programadores mudarem apenas duas palavras e gerarem erros catastróficos em todo o sistema.

Aaaaaa, mas se eles tivessem executado os testes isso não teria acontecido

Sim, iria. O teste esperava um update, porém foi removido os filtros do update, alterando todos os resultados da base. Durante o teste isso não era verificado.

Ele deveria ter feitos mais testes para prever esses casos

É claro, programadores mais maduros conseguem prever alguns problemas, esses não são errados. Mas atirar no escuro, sem base nenhuma, sempre vai ser um problema.

Em um sistema pequeno ter testes desnecessários, quase não é perceptível, porém ter testes desnecessário significa: lentidão na de rodar sua suíte de testes e tempo desperdiçado.

Portanto o melhor a ser feito é focar seus testes naquilo que a história pede, e nos casos de bugs, acrescentar um novo teste para cada correção. Cobrindo os problemas e mantendo a integridade da história. 




Comentários

  1. Casinos in Las Vegas | JTM Hub
    Casino games in Las 충주 출장마사지 Vegas, NJ · 제주 출장안마 Caesars Palace · Golden Nugget Casino · Caesars Palace · Wynn Las 영주 출장마사지 Vegas · 의정부 출장안마 Tropicana Atlantic City · The LINQ Hotel & Casino 군포 출장마사지

    ResponderExcluir

Postar um comentário

Postagens mais visitadas deste blog

Gerenciando projetos remotos com Github

É estranho o número de pessoas que me perguntam como fazer para desenvolver em um grupo remoto.  Resolvi colocar com base nas minhas experiências montar esse postagem. Planejamento O planejamento do software é criado pela equipe de Análise, normalmente esse pessoal tem um contato maior com o Cliente, nesse caso existe reuniões constantes para manter em sintonia as espectativas. Quando se trabalha com métodos ágeis o Project Owner (PO), são eles que trazem os requisitos e demandas. Algumas empresas utilizam-se de vídeo conferencia, outras apenas reuniões presenciais, se me perguntar qual eu prefiro para esse caso, é uma reunião presencial. Caso não seja possível, pelo menos uma video conferencia. É extremamente importante que não exista falha de comunicação nessa parte para o sucesso do projeto. Gerenciamento de Tarefas O gerenciamento de tarefas é divido em duas partes. Milestones para quem trabalha com métodos ágeis isso seria chamado de Sprint, que como reza o Scrum n

django-choices-flow 0.8.5 (stable)

Motivação: Precisava controlar a transação dos status de um Model do Django, evitando por exemplo que o usuário mudasse o status de um registro de cancelado para novo. Documentação do projeto: https://django-choice-flow.readthedocs.org/en/latest/ Repositório do projeto: https://github.com/valdergallo/django-choices-flow