Artigos

Seu projeto não tem testes? Pior pra ele

Olá pessoal! Esse é o meu segundo post aqui no blog do Tá Safo! e desta vez vou falar sobre testes e TDD que é um tema ainda pouco discutido pela região.

Bem, eu vejo em muitos lugares, inclusive em gerências de projetos por ai que uma tarefa é dividida nos seguintes estágios: A Fazer, Fazendo, Testando, Homologação e Pronto.

A primeira é quando a funcionalidade ainda está a espera de ser implementada, a segunda é quando alguma criatura começa a produzir a tarefa (que no nosso caso, é o código). Então, após ser implementado ele será testado para depois ser aceito pelo cliente e pronto, fim de papo.

Sempre que assisto a alguma palestra ou converso com alguém sobre o que este teste realmente quer dizer, ouço que é alguém dedicado a usar o software para saber se a funcionalidade feita está de acordo com o esperado e/ou funcionando.

Cruzes! Toda vez que escuto isso me dá um frio na espinha, sério. Primeiramente, existe uma pessoa dedicada para isso. Segundo, o teste é feito manualmente. Terceiro, o teste é feito DEPOIS que o código é escrito.

Óbvio, hehe, o terceiro ponto pareceu muito esquisito. Não tem como testar a função antes dela ter sido implementada. Quebremos, então, este paradigma.

Apresento-lhe os testes automatizados. Você, desenvolvedor, escreve um teste que valida algum código em produção. Este teste deve rodar automaticamente com uma única linha de comando ou um clique de um botão e deve sempre passar após ele ser implementado.

Perceba que você escreverá 2 vezes mais código (mentira, serão 4 vezes mais código). Sim, é verdade, e este é uma das inúmeras quebras de paradigmas que você precisará passar.

Imagine que todo o seu código foi testado, todos os testes estão passando e você verifica que todo o software está funcionando como esperado em segundos! Qualquer desenvolvedor, “testador”, analista, quem seja, poderá rodar os testes.

Perceba também que não existe mais um papel separado para o testador, o desenvolvedor já é o testador do código. O caso é que somente testar o código e faze-lo passar não é o suficiente para trazer segurança no seu código.

É ai que vem o TDD (Test Driven Development) que significa Desenvolvimento Dirigido a Testes. Nele existem três regras básicas:

  1. Você não tem permissão de escrever qualquer código de producão a menos que seja para fazer um teste passar.

2. Você não tem permissão de escrever mais nenhum teste que o suficiente para falhar.

  1. Você não tem permissão de escrever mais nenhum código de produção do que o suficiente par afazer o teste passar.

[ http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd ]

As três regras resultam em algo mais resumido que é o chamado ciclo Red Green Refactor (Vermelho Verde Refatorar). Isso significa que você deve primeiro, sempre, escrever um teste que falha (Vermelho) para então escrever código de produção que faça o teste passar (Verde) e com ele passando, refatore o código para que ele fique limpo e mais fácil de entender.

Se você seguir estas regras, seu código terá sempre 100% de cobertura e no momento que o cliente pedir uma alteração em uma funcionalidade, você poderá saber onde a alteração quebrou código em qualquer lugar do projeto!

Você não terá mais aquele medo enorme ao mudar o código, pois você saberá exatamente onde modificar para que o software funcione sempre como esperado!

Lembre-se dos princípios ágeis onde a mudança é algo esperado e mudar o mais rápido possível, com código funcionando, é um dos maiores princípios que a agilidade nos traz.

Depois desta introdução, eu tentarei mostrar mais tecnicamente como criar testes automatizados e o ciclo do TDD em futuros artigos aqui no TÁ Safo!, então fique ligado!

Além disso, eu tenho um Lightning Talk no Tá Safo Conf 2012 que mostrarei exatamente como trabalho com TDD no trabalho e rodarei os testes ao vivo para vocês verem como é maneiro! Não deixe de votar no meu talk e também de se inscrever no evento! O tempo está correndo!

9 Comentários

  • Alan Marcel

    Em um cenário corriqueiro que “tudo é para ontem”, você acredita que o próprio desenvolvedor deve fazer suas tarefas normais (programar) e ainda testar as funcionalidades ou um tester deve ser contratado e se dedicar aos testes? Ao ler o seu texto, isso não ficou muito claro para mim.

  • Felipe Iketani

    Olá Alan! Excelente pergunta!

    Sim! O desenvolvedor e SEMPRE o testador, e ele deve SEMPRE testar o código antes de desenvolver.

    eu não listei outras vantagens do TDD em sim, mas o que muita gente pensa, e isso é um paradgma, é que testar o código atrasa a produção, o que não é verdade.

    Existe sim uma curva de aprendizado, mas depois a verdade é que a produção aumenta MUITO quando se faz TDD, o motivo? É porque se gasta muito mais tempo fazendo manutenção de código, debugs etc do que escrevendo o código.

    É por isso que ter uma boa suite de tests na verdade agilizado todo o processo de desenvolvimento, manutenção e publicação do software!

    vlw pela pergunta! poderá ser esclarecida em outro post

  • Adriano Ohana

    Perfeita a colocação Felipe. A ideia é cada vez nos aproximar-mos dos testes automatizados em nosso Dia a dia.

    Porém em um futuro artigo sobre o assunto seria bacana uma abordagem prática para darmos os primeiros passos nessa quebra de paradigma.

    Uma dúvida que eu tenho. Assim como temos hoje os testers em algumas empresas para alguns cenários, não seria interessante dividir essa carga com os desenvs e quem sabe criarmos Testers de Código ??? O cara que ficaria realmente responsável por fazer o código de Testes ???

    Haveria algum empecilho pra isso ???

    • Felipe Iketani

      Olá Adriano!

      Acredite, é completamente possível (e desejável) escrever os próprios testes. Sim, existe a curva de aprendizado e a grande quebra de paradigmas, mas a partir do momento que se “engata a quinta marcha”, você nunca mais vai querer desenvolver sem testar.

      Dizemos que o teste e seu código são irmãos siameses, eles não andam separados. Logo, os desenvolvedores escrevem o teste antes do código de produção. E o motivo é simples…

      Você, nem ninguém, sabe como o código de produção irá ficar. Existe o pessoal que fazem os diagramas de classes e tudo mais, entretanto nem sempre o que eles decidiram é o código final, não é mesmo? O mesmo iria acontecer se outras pessoas escrevessem os testes.

      Não tem como escrever mil testes e depois ir desenvolvendo o código de produção. O modo que o TDD funciona é bem mais granular. Você escreve um pequeno teste que falha e faz ele passar. Escreve outro e faz ele passar. E assim por diante.

    • Felipe Iketani

      Olá Marcel, sim!

      os testes devem englobar tudo o que o software deve fazer e claro, as regras de negócios. A final, o software é criado a partir deles!

      Os testes tem vários níveis, que irei mostrar no meu lightning talk no Tasafo Conf 2012.

      Dá, inclusive, para fazer cm que seus testes abram o navegador web e vá clicando em links, preencha formulários, clique em botões, tudo automaticamente. Se tudo funcionar, é porque o teste passou 🙂 Esse é o tipo de teste mais alto nível de todos.

      Existem os testes de integração, que testam seu software com o de terceiros para saber se ele se integra corretamente com ele ( como um exemplo ).

      Outra forma de testar é o teste unitário, onde se testa cada classe criada para saber se ela se comporta como o esperado.

      Numa estatística, os especialistas dizem que deve se formar uma pirâmide de cobertura destes 3 tipos de testes: meio que 10% para os testes de interface de usuário, 30% de integração e o resto, unitários.

  • Paulo Moura

    Adriano, será que se agente deixasse o QA testar código não seria meio cascata? Acho que devemos começar a incorporar à nossa cultura a questão de testar nosso código. Não tem tempo pra criar testes? Como assim? Se os testes fazem parte do trabalho de programação. A maioria já faz isso, mas faz meia boca. Quando tu dá um System.ou.println(“A bagaça funciona”), já estás testando. Mas porque não automatizar isso?
    TDD é legal, mas testar já é de bom tamanho. Acho que precisamos primeiro aprender a testar, para depois aprendermos TDD.

  • Paulo Moura

    Alan Marcel, complementando o que o Felipe disse, TDD abrange muita coisa, por exemplo, existem variantes dele como o BDD (Desenvolvimento Guiado por Comportamento) e o ATDD (Desenvolvimento Guiado por Testes de Aceitação).
    Hoje com inúmeras ferramentas, testar já não é uma tarefa trabalhosa como era antes. Hoje, os testes podem ser escritos em linguagem natural, o que facilita inclusive a comunicação. E o que nos impossibilita de criar testes automatizados é a nossa cultura. Tem ficar claro é que testar não é a mesma coisa que usar TDD. O TDD é mais direcionado a se criar um design melhor. Mas nem sempre é possível utilizá-lo. No entanto devemos sempre testar nosso código.

Deixe um comentário para Adriano Ohana Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *