[photopress:logo.gif,full,alignleft] Na edição 29 da revista MundoJava escreví sobre o dia a dia de um agilista. Continuando uma série sobre TDD na Revista MundoJava nesta edição escreví um artigo sobre a ferramenta FIT para automação de testes. O artigo teve participação de Ivan Sanchez e James Shore.
O Ivan Sanchez foi o cara que fez o treinamento CSM junto comigo no início de 2007, e teve o azar de cair no mesmo grupo comigo! O Ivan é um agilista e grande evangelista de Coding Dojos. Atualmente trabalha na Signature Technologies no Reino Unido.
James Shore (Jim) é lider do projeto FIT (criado por Ward Cunningham), atua em projetos ágeis desde 1999 (sim, existem projetos ágeis antes do Manifesto Ágil) e escreveu o livro “The Art of Agile Development“.
Uma das coisas legais de escrever na MundoJava é ter contato com esses caras lá de fora e poder trazer estes conteúdos para nossa comunidade. Escrever com o Scott Ambler e o Jon Kern foi muito legal. Este artigo com o James Shore também foi especial. Infelizmente eu recebo mais não do que sim, mas ainda vou continuar insistindo com os mestres! Ah… vocês querem o trecho grátis do artigo, certo? Então aí vai:
Uma das questões comuns é: Quem escreve os dados de teste? Pela estratégia do FIT, os dados de teste são escritos a “oito mãos”. É comum que tudo inicie com o usuário ou cliente e com o analista de negócios, capturando cenários de teste iniciais que formatam alguns critérios de aceitação. Depois disso, um desenvolvedor pode verificar a formatação das tabelas, referenciar as Fixtures e assim obter o RED do ciclo TDD. Ao mesmo tempo os testers podem participar colocando mais cenários. Logicamente, o FIT é uma ferramenta ágil. É importante uma rica colaboração face a face de todos os envolvidos para que exista sucesso na adoção dessa abordagem.
Uma atenção especial deve ser dada ao trabalho do analista de negócios. Atualmente é comum que esses profissionais capturem requisitos em documentos texto e alguns diagramas. Geralmente este tipo de abordagem é muito pobre para o desenvolvedor, principalmente se não existe uma comunicação rica entre eles. Comunicação com documentos é uma forma muito pobre de comunicação (veja artigo “Modelagem Ágil”, MJ 27). Um modelo de requisitos em texto é muito deficiente na maioria das vezes. Pare para pensar: Não existe teste sobre documentos em texto e nem compilador para diagramas!
Rodrigo Yoshima
O que é o FIT e porque se importar com ele? O FIT é parte do seu arsenal ágil de prevenção de bugs. Diferente da abordagem tradicional para a qualidade, onde focamos em encontrar e remover defeitos, as práticas ágeis focam-se primeiramente em previnir que bugs sejam criados. Isso nos leva a alguns resultados impressionantes. Times ágeis experientes produzem poucos bugs por mês.
As “práticas ágeis de engenharia” pregadas pelo Extreme Programming (XP) são parte da solução. Essas técnicas como Test-Driven Development (TDD), programação aos pares, propriedade coletiva do código, design simples e trabalho energizado previne a maioria dos erros de programação. Elas garantem que o código faz exatamente o que os programadores pretendiam que ele fizesse.
James Shore
FIT ou Framework for Integration Testing é uma ferramenta excepcional no auxílio ao desenvolvimento de um software. O cliente (ou analista de negócio) escreve tabelas mostrando o que o sistema deve fazer através de exemplos. O desenvolvedor escreve o código das fixtures, que são as classes que ligam as tabelas com o sistema que está sendo implementado. A partir daí as tabelas se tornam “executáveis” e as regras definidas podem ser validadas de maneira automatizada.
FitNesse é a implementação mais popular de FIT, que funciona na forma de um wiki. Cada página representa um teste executável e é possível executar múltiplas páginas para validar um sistema como um todo. Além disso, por se tratar de um wiki, favorece a colaboração entre cliente e desenvolvedores, podendo servir como uma ótima base de conhecimento sobre o sistema que está sendo construído.
Ivan Sanchez
O FIT é uma ferramenta muito interessante: Uma coisa que chama a atenção em projetos onde utilizamos o FIT é que produzir as tabelas com os dados de teste é uma atividade de modelagem intensa. Modelar não é fazer diagramas, é muito mais profundo do que isso!
Já nas bancas!