Feeds:
Posts
Comentários

Posts Tagged ‘TDD’

Depois de uma semana afastado, retornei a empresa pra ver como as coisas estão andando e para continuar o treinamento. Agora para apresentar o test driven development.

Assim que entrei na empresa, tive uma boa supresa. Eles colocaram mais um quadro na empresa. Agora eles tem um quadro para as tarefas e outro onde ficam os itens das retrospectivas e os itens mais importantes do product backlog.

Além disso, pelo que observei está tudo indo bem, as coisas não estão ótimas, contudo eles estão melhorando aos poucos e isso é o importante.

Como já comentei aqui no blog, eles estão utilizando PHP para desenvolver o projeto novo deles. Então fui dar uma olhada no que havia de novo no PHPUnit, preparei uma apresentação bem simples para explicar os conceitos do TDD.

Comecei com o clássico “TDD não é teste, TDD é uma forma de desenvolver o sistema de uma forma incremental”. Repeti isso umas cinco vezes no início e mais algumas durante os exercícios. Depois disso expliquei o ciclo do TDD, comentei que para classe desenvolvida, deve existir outra classe de testes e falei sobre design, a mudança que é evitar aquele pensamento enorme inicial de como algo deve ser para pensar em um design que vai evoluindo junto com a classe.

Depois fui para uma parte mais prática, expliquei que toda classe de teste vai ser um sub-classe de uma classe do PHPUnit (o que é algo ruim, no JUnit4 não precisa fazer isso) e que todo método de teste tem a assinatura:

public function testMetodoDeveTerComportamentoTal{}

Algo que eu também dei bastante ênfase, é no nome do método de teste. Como o PHPUnit não permite a utilização de contextos, o nome deve ser grande e claro, pra ser facilmente entendido o que o teste está testando. Além disso, também lembrei eles que cada teste deve testar apenas um item. Pra exemplificar isso citei uma classe imaginária Calculadora, nos testes você pode ter os métodos testDeveSomar500Com300 e testNaoDevePermitirDivisaoPorZero mas não deve ter apenas um método de teste que garanta que a calculadora deve somar e não aceita divisão por zero. Ou seja, One Assertion Per Test.

Depois disso já pedi para eles abrirem a IDE por eles utilizada (Zend Studio), ela já tem um suporte legal para o TDD, embora utilizar o PHPUnit que vem junto com a IDE é sofrível, muito, muito lento.

Então o primeiro exercício foi criar uma calculadora. Desenvolver uma calculadora é extremamente simples, mas a idéia era que eles tivessem algum contato com o PHPUnit sem se preocupar com o problema que iriam resolver.

Ao criar um novo TestCase, a IDE já criou os métodos setUp() e tearDown() e já fez da classe de testes uma sub-classe de PHPUnit_Framework_TestCase. Aproveitei esse momento para explicar que o método setUp() é chamado sempre antes de cada teste e o tearDown() é chamado sempre depois que cada teste é executado. Também expliquei qual o motivo de existirem esses métodos.

Continuei o exercício explicando as funcionalidades a medida que era necessário. Depois que eles criaram a assinatura do primeiro teste, expliquei como é feito a asserção no PHPUnit e apresentei as mais utilizadas (assertEquals assertTrue assertFalse assertNull assertNotNull). O exemplo da calculadora foi útil também para apresentar como funciona a asserção de exceções no PHPUnit.

No final desse exercício, eles tinha uma boa idéia de como funciona o PHPUnit e como os testes do TDD podem ajudar na garantia que não seja adicionado nenhum bug num sistema com testes. Contudo eles ainda não tinham idéia de como o TDD pode ajudar no desenvolvimento.

Isso eu deixei para o segundo exercício. Deixei 2 horas separadas para esse exercício, que basicamente funcionava da seguinte forma.

Eu, cliente, quero um sistema no qual eu entre um valor numérico, por exemplo 327 e o sistema deve retornar o número por extenso, no caso, trezentos e vinte e sete. Os número podem variar de 0 até 999.999 com duas casas decimais.

Escolhi esse exercício pois considero que o desenvolvimento incremental do TDD se beneficia muito de um exercício como esse.

A primeira reação deles ao ouvir o exercício foi pegar um papel e começar a esboçar a solução, com exceção de um desenvolvedor, que foi para o google procurar algo pronto. Nesse momento pedi para eles sentarem em duplas e conversei para mostrar como TDD ajuda a resolver o problema. Comecei dando a idéia de resolver primeiro de 0 até 10, depois de 11 até 20. Mostrando pra eles que quebrando o problema iria ficar muito mais simples para resolver.

Eles aceitaram a idéia e começaram a escrever código. Foi muito legal que eles pegaram o espírito do TDD, eles foram desenvolvendo um teste de cada vez, fazendo cada teste passar antes de evoluir o código, além de ficar refatorando constantemente.  As duplas também eram trocadas a cada 30 minutos,  para garantir um ritmo parecido em toda equipe.

No final de 2 hoas o resultado foi muito bom. Todos haviam gostado do que haviam produzido e de como haviam produzido. Diferentemente do que aconteceu comigo, que demorei uns 3 meses para cair na real com TDD, aparentemente eles pegaram bem o espírito e gostaram. Já perguntaram como eles vão utilizar no projeto atual deles!

Abri um espaço para dúvidas no final, contudo somente uma apareceu.

TDD é legal, mas quando o código é muito simples, não preciso fazer isso, não é?

A minha opinião é que mesmo códigos muito simples devem ser testados. Códigos muito simples geralmente possuem testes muito simples, então o tempo para escrever somente o código da classe ou a classe e o teste vão ser pequenos. Outro problema é que é comum ter um código simples no início, contudo conforme o sistema cresce o código também cresce. Por último, TDD ajuda a ter um código sem bugs e mesmo em códigos simples podem escapar alguns bugs. Então para mim código simples está longe de ser um motivo para não utilizar TDD em uma classe.

É isso, na próxima semana vou falar sobre dummies, fakes, stubs e mocks.

Read Full Post »

Mock Dialogue

Mock Dialogue é outra apresentação que teve na Ruby Hoedown 2008, essa foi feita por Joe O’Brien e Jim Weirich.

Essa apresentação foi feita forma de diálogo, um teatro. Um desenvolvedor  está iniciando com mocks/stubs/fakes e o outro desenvolvedor já conhece e utiliza mocks/stubs/fakes e vai ensinando para o outro. A apresentação é dividida em 3 atos, em cada ato esse desenvolvedor aprende algo e as questões para o próximo ato ficam mais interessantes.

Nessa apresentação você vai ver sobre boas práticas ao utilizar TDD, mocks, stubs, fakes, fluent interface, flexmock x mocha, overmocking entre outros.

Read Full Post »

Test All The Fucking Time é o título de uma Lightning Talk que Brian Liles fez na Ruby Hoedown 2008.

São apenas 12 minutos, onde a mensagem principal é: Test All The Fucking Time!

Vale a pena assitir!

Read Full Post »

Já fiz minha pré-inscrição para o 1º Seminário Catarinense de Qualidade e Teste de Software.

Olhando as palestra, acho que a maior parte vai ser enrolação e/ou propaganda, mas mesmo assim acho que vai valer a pena dar um pulo até Floripa.

Fica aí a dica, mais alguém vai estar presente por lá?

Read Full Post »

No embalo do post de ontem, outro artigo do Miško Hevery com coisas que você deve evitar no seu projeto.

Nada de novo, nada de excepcional, mas são regras que você deve ter sempre em mente (talvez escrito em algum cartaz em uma parede/quadro) enquanto programa.

Read Full Post »

Este artigo, escrito por “Miško Hevery, Jonathan Wolter, Russ Ruffer, Brad Cross, and lots of other test infected Googlers” tem um ótima lista de coisas que você não deveria estar fazendo com seu código… é uma lista bem completa, leitura recomendada!

Read Full Post »

Acabei de assistir a apresentação que Tammer Saleh (criador do shoulda) deu na RubyConf desse ano.

Ele começa a apresentação comentando sobre o shoulda e somente por isso você já deveria assistir, shoulda é bem interessante, pretendo começar a utilizá-lo logo.

Contudo, o melhor vem depois que ele faz a apresentação do que é e como funciona o shoulda. Tammer fala sobre alguns assuntos que envolvem TDD/BDD, como a utilização ou não de fixtures, cenários com fixtures, whitebox tests x blackbox tests entre outros.

Vale a pena ouvir as dicas e conselhos que Tammer dá nesse screencast.

Read Full Post »

Older Posts »