Danilo Sato

O David Chelimsky, core developer da equipe do RSpec, anunciou hoje o lançamento da versão 1.1.0 na lista de discussão do projeto. Essa versão é um grande marco para o projeto, trazendo novas funcionalidades e diversas melhorias:

• Story Runner: Como já falei aqui no blog, o projeto RBehave foi integrado ao core do RSpec, ganhando o nome de Story Runner. Com isso, o RSpec se torna um framework full-stack para BDD. Além de definir o comportamento do seu código, você também pode colaborar com seu cliente através de cenários executáveis, escrevendo os testes de aceitação para sua aplicação. A possibilidade de escrever story tests em texto puro é um grande passo nessa direção. Quem assistiu minha palestra no Rio on Rails teve a oportunidade de ver uma demonstração dessa funcionalidade.
• Integração com o Rails 2.0: A nova versão está integrada com o novo Rails 2.0. O plugin RSpec on Rails também foi atualizado para aproveitar a funcionalidade dos story tests na sua aplicação Rails.
• Transição fácil do Test::Unit: Uma funcionalidade bem interessante para quem está migrando do Test::Unit para o RSpec. Para migrar, você precisa apenas:

1.  
   1. incluir um ‘require spec’ no seu arquivo de teste;
   2. trocar a definição da subclasse de TestCase ‘class ClassContextTest < Test::Unit::TestCase’ por uma descrição do tipo ‘describe “class in context” do’;
   3. Converter os métodos de teste ‘def test_should_do_this’ por blocos ‘it “should do this” do’;
   4. Transformar asserts ‘assert_equal 2, some_calculation’ em shoulds ‘some_calculation.should == 2′;
   5. remover a dependência com Test::Unit, removendo o ‘require ‘test/unit’

• Exemplos encadeados: Agora você pode escrever um bloco “describe” dentro de outro.

Essa era a notícia que eu estava esperando desde minha primeira palestra sobre o assunto na RejectConf’SP) e, depois do lançamento do Rails 2.0 na semana passada, a integração com o RSpec finalmente chegou. Aproveitem!

 

sudo gem update rspec

 

Esse fim de semana tive a oportunidade de conhecer o Rio de Janeiro e participar do Rio on Rails, organizado pelo pessoal da ImproveIt. O sábado foi repleto de Ruby e Rails e no domingo tive um tempinho para passear e conhecer um pouco da cidade maravilhosa.

 

 

Os organizadores estão de parabéns. As palestras foram muito bem escolhidas e acho que deram um bom gostinho de como é divertido programar em Ruby e Rails para quem nunca tinha experimentado. Como sempre, eventos são uma excelente oportunidade de conhecer gente nova e trocar experiências e o Rio on Rails não deixou a desejar. Conheci o Ronaldo Ferraz, que falou um pouco sobre DSLs, o Demetrius Nunes, um dos pioneiros na adoção de Rails no Brasil, o Eduardo do site o Curioso, todo o pessoal da Improveit e do projeto Lucidus e mais um monte de gente que não vou lembrar do nome, mas que estavam presentes para fazer mais um grande evento da comunidade Rails no Brasil.

 

 

Minha palestra sobre BDD e RSpec foi uma evolução da palestra no RejectConf’SP. Com mais tempo para explicar os conceitos e fazer uma demonstração mais calma, acho que consegui passar uma idéia melhor da experiência de programar com BDD em Ruby e Rails. Os slides já estão disponíveis aqui, assim como o esqueleto da aplicação demo que desenvolvi, com o passo-a-passo da demonstração. Quem quiser também consegue pegar a versão final do código apresentado.

 

 

Uma coisa legal que eu consegui terminar de preparar para a apresentação foram algumas das novidades do RSpec 1.1.0, como o Story Runner (integração com o RBehave, que eu apresentei no screencast do Dojo@SP), os plain text story tests e o protótipo do editor de story tests no browser.

 

 

Para rodar os exemplos, você precisará do Rails 1.2.6 (não fiz update pro 2.0 na palestra pois o patch da integração do RSpec com o Rails novo saiu na sexta a noite e não quis arriscar a demonstração ao vivo), do RSpec e do Rcov, caso queira verificar a cobertura (gem install rcov). Quem gostou da integração do Autotest com o Growl que eu usei na demonstração, pode pegar meus arquivos de configuração no Google Groups do Dojo@SP (não esqueça de instalar o Autotest com ‘gem install ZenTest’).

 

Esse fim de semana participei de mais um evento que não estava planejado (essa é a graça de ser ágil, não?), o WebDevCampSP 07. Apesar do evento contar com um número menor de participantes, gostei bastante por ser mais “intimista”. O estilo “desconferência” acabou me contagiando e, depois de assistir as palestras do sábado e de conversar com o Akita e o Dairton acabei preparando uma mini-palestra sobre testes.

A palestra foi curta, mas minha idéia era encarar o assunto de outro ponto de vista: ao invés de falar as vantagens de testar seu código, foquei nos riscos que a falta de testes pode causar. Além disso, falei um pouco também sobre diferentes tipos de teste, ferramentas que podem facilitar sua vida e fiz uma demonstração de como gravar um teste de aceitação do Selenium com o Selenium-IDE. Se você se interessar pelo assunto, os slides já estão disponíveis.

Foi bom reencontrar amigos e conhecer novas pessoas. Os organizadores e patrocinadores estão de parabéns! Foram dois dias de aprendizado, troca de experiências e networking. O evento tem tudo para crescer e fazer sucesso no ano que vem.

Lembrando que no próximo fim de semana estou embarcando para o Rio on Rails. Quem estiver interessado na minha palestra e não puder comparecer, vai ter a chance de assistir um “demo” na próxima reunião do Dojo@SP. Espero vocês lá!

 

Continuando com a maratona, participei de mais um evento excelente. Sou um pouco suspeito para falar pois dessa vez tive a oportunidade de ajudar na organização do primeiro RejectConf para a comunidade Ruby e Rails brasileira. Não posso deixar de agradecer ao Akita, à Caelum e ao Prof. João Eduardo Ferreira do CCSL/IME-USP pelo apoio e ajuda na organização do evento.

 

 

Apesar de termos atrasado um pouco o cronograma, já sabíamos que isso podia acontecer (big design up-front não funciona :P). No entanto, a qualidade dos palestrantes e a participação do público em geral superou e muito minhas expectativas.

 

 

Foi muito bom conhecer algumas pessoas pessoalmente, como o Eduardo Fiorezi, o Vinicius, Tapajós e o pessoal da ImproveIt, além de reencontrar amigos e conhecidos, como o Carlos Villela, o Fernando Meyer, o Fabio Kung, Paulo e Jonas da Caelum, o Hugo e o George (ainda não o conhecia) do Pagestackr, meus amigos do IME (Pedro, Dairton, Giuliano, Fabricio, Jef) e muitos outros que com certeza estou esquecendo de listar.

 

 

Palestras e Palestrantes

 

Do ponto de vista técnico, todas as palestras foram excelentes. O conteúdo abrangia diferentes níveis de conhecimento, agradando aos iniciantes e aos desenvolvedores mais avançados. Todo o material vai ser disponibilizado, assim como os vídeos gravados no evento.

 

Os palestrantes estão de parabéns! Foi incrível como algumas palestras pareciam se “linkar” umas com as outras. Parecia até que havíamos combinado algo antes :-)

 

RSpec e RSpec on Rails

 

Minha palestra foi curta e, apesar de uns probleminhas técnicos (bugzinhos), correu tudo bem. Eu falei brevemente sobre o conceito de Behaviour-Driven Development e mostrei um pouco de código ao vivo. Desenvolvi uma aplicação demo para obter feedback (positivo ou negativo) das palestras e deixei meu notebook ligado para quem quisesse votar durante o evento. Apesar de alguns problemas com a rede wireless, algumas pessoas conseguiram acessar e votar. Tirei um screenshot do widget criado pelo Safari 3 mostrando o resultado final da votação. É claro que o placar é irrelevante a não ser pelo fato de que o coffee-break venceu disparado!! :-)

 

 

Os slides da minha palestra já estão disponíveis para download, assim com o código-fonte da aplicação demo e as notas que usei na implementação ao vivo.

 

 

Se você tem alguma sugestão para melhorar minha palestra, por favor deixe um comentário. Você gostou ou não gostou da minha palestra? Aprendeu alguma coisa? O bug na demonstração atrapalhou muito? Você prefere ver código ou slides? Essa palestra será a base do que vou apresentar no próximo evento de dezembro, o RioOnRails, por isso sua opinião é muito importante. Lá terei mais tempo para elaborar os conceitos e mostrar um demo mais completo e detalhado. Espero vocês lá!

 

 

Mais uma vez, todos os que participaram estão de parabéns. Tenho consciência que podemos melhorar muitas coisas para o ano que vem, mas o importante é que demos o primeiro passo. Acredito que daqui pra frente a comunidade Ruby e Rails brasileira só tende a crescer.

 

Final de feriado chegando. É hora de voltar a ativa e contar como foram os eventos da última semana. Primeiro um pouco sobre o Conexão Java.

 

 

Sexta-Feira

 

Foi a primeira vez que participei do Conexão Java e gostei bastante do evento. Além de re-encontrar amigos, as palestras que assisti foram excelentes. Na sexta-feira o Alexandre Magno falou um pouco sobre Scrum e, apesar de ter precisado sair no meio da palestra, os comentários que ouvi foram todos positivos. Na sexta acabei assistindo só essa palestra, pois fiquei o resto do dia ajudando o Carlos Villela terminar seus slides (percebam que minha participação foi importante.. he he).

 

 

Sábado

 

No sábado, o keynote do CV criticou os “arquitetos de uma nota só” que preferem usar sempre a mesma ferramenta para resolver qualquer problema. Além de argumentar sobre a importância da plataforma Java vs. da linguagem Java, os tópicos levantados deixaram a platéia preparada para as próximas apresentações.

 

 

O Philip Calçado re-apresentou a palestra de arquitetura do Just Java (dessa vez sem o Paulo) e agradou bastante o público. Apesar de eu já ter assistido a palestra, foi bom para ouvir mais um pouco sobre as “arquiteturas Java do passado”. Particularmente achei muito valioso ele ter levantado temas recentes como Domain-Driven Design e DSLs.

 

 

Depois foi minha vez. Minha estréia como palestrante foi bem recebida. As pessoas que me procuraram depois da palestra me deram um feedback positivo e alguns comentários online que li (aqui e aqui) me deixaram bastante feliz com o resultado. Espero que tenha conseguido passar minha mensagem, deixando algumas sementes para discussão sobre Métodos Ágeis, XP, Scrum e Lean. Minha apresentação já está disponível para download aqui.

 

 

Após minha palestra fomos almoçar numa churrascaria e acabei perdendo a palestra do Vinícius. A última palestra do dia foi do Fernando Meyer, core developer do JBoss, sobre ANTLR e seu uso na criação de DSLs externas. Gostei pois ele mostrou os conceitos básicos de um compilador (parsing, análise léxica, análise semântica, interpretação, geração de código, etc.) e partiu para um exemplo prático de código. Dei uma ajudinha depois da palestra com um bug (essas coisas acontecem) e os slides e o código estão disponíveis no blog do Fernando Meyer.

 

 

Espero poder participar de mais eventos como esse. Se você assistiu minha palestra, deixe algum comentário (positivos ou negativos). Feedback é sempre importante e me ajudará a melhorar para as próximas apresentações. O que você gostou e não gostou da minha palestra? Você aprendeu alguma coisa? Algumas das idéias surtiram efeito no seu dia-a-dia?

 

Já faz um tempo que estou para falar das novidades e, depois das palestras em novembro/dezembro, é com orgulho que apresento o novo curso de XP na Caelum.




Eu sou um pouco suspeito pra falar bem dos cursos deles, pois não só sou amigo do pessoal de lá, como também ajudei a montar esse novo curso. No entanto, posso garantir que a preocupação deles com a qualidade do treinamento, do material, a didática e, principalmente, com o aluno é um diferencial em comparação aos cursos encontrados no mercado. É por isso que fiquei feliz com o convite para ajudar a montar esse curso e ministrar a primeira turma.




O conteúdo está muito legal e quem participar vai aprender e se divertir. O treinamento terá um enfoque bastante prático, e exigirá que os alunos programem bastante. Minha meta nessas 20 horas de curso é falar não só sobre a filosofia Ágil, os princí­pios e valores de XP, como também mostrar os aspectos técnicos e mostrar a sinergia entre as práticas da metodologia. Espero que o aluno saia do treinamento com diversas idéias novas para implantar na sua empresa.




Fico bastante feliz que novos cursos desse tipo estão aparecendo no mercado de software nacional. Isso só vem a reforçar o fato de que os Métodos Ágeis estão ganhando mais interesse no Brasil a cada dia que passa.




Quem estiver interessado em participar, é só entrar em contato com o pessoal da Caelum para mais informações ou para fazer a reserva.

Se você é de São Paulo ou do Rio de Janeiro, nunca me (ou)viu falar ao vivo e estiver interessado em me conhecer para bater um papo, vai ter algumas chances nos próximos meses. Depois de participar de um evento de Software Livre, de XP e de Python nesse ano, vou apresentar algumas palestras para a comunidade Java, Ruby e Rails. Detalhes a seguir…

09/Nov e 10/Nov: Conexão Java '07 Hands On

No dia 10 de Novembro, das 11:30 – 13:00, vou apresentar uma palestra sobre Métodos Ágeis chamada “Agile Methods for the Traditional Guy”. Espero que o título não assuste as pessoas, pois o tema é legal e a idéia é dar uma introdução geral sobre os princípios do Manifesto Ágil, XP, Scrum, Lean, discutir problemas dos métodos tradicionais e desmistificar alguns mitos sobre Métodos Ágeis. As inscrições podem ser feitas pelo site do evento (com desconto até o dia 31/Out) e o evento acontecerá na Universidade Anhembi Morumbi da Vila Olímpia.

Quem for participar terá a chance de assistir ótimas palestras de alguns amigos: o Carlos Villela vem apresentar o keynote e falar sobre o “Arquiteto de uma nota só”; o Phillip Calçado vem reapresentar a ótima palestra sobre arquitetura do JustJava (dessa vez sem o Paulo), além de coordenar uma atividade que promete ser divertida: a Oficina do Arquiteto; O Fernando Meyer vai falar sobre DSLs e ANTLR; o Alexandre Magno vai falar sobre Scrum, dentre outras palestras muito boas.

Além das palestras, estarão acontecendo também mini-cursos em paralelo. O pessoal da Caelum vai ensinar Hibernate, AJAX e JSF, Java ME e JPA. Pelo que conheço da qualidade dos cursos deles, são mini-cursos ótimos e imperdíveis se você estiver interessado em aprender um pouco sobre essas tecnologias.

17/Nov: RejectConfSP '07

No fim de semana seguinte (sim, no meio dos feriados) estou ajudando o Fabio Akita a organizar a primeira RejectConf em São Paulo. A idéia é juntar a comunidade Ruby e Rails para mini-apresentações (de 10 a 30 minutos) sobre diversos assuntos, além do networking, troca de conhecimentos e diversão :-)

O evento vai acontecer no IME-USP, no Auditório Jacy Monteiro, das 11:00 – 17:00. As inscrições são gratuitas estão atualmente com lista de espera, mas pode ser feitas neste formulário. Quem estiver interessado em apresentar algum tópico, basta preencher este outro formulário.

Minha mini-palestra será sobre RSpec e RSpec on Rails. Quem quiser um gostinho de como é programar com RSpec/RBehave pode assitir o screencast #01 do Dojo@SP.

08/Dez: Rio on Rails

Por fim, mais um evento da comunidade Rails, organizado pelo Vinicius e o pessoal da Improve It. O evento está confirmadíssimo e acontecerá no SENAC, das 9:00 – 18:00. As inscrições custarão R$50,00 e estarão disponíveis em breve no site do evento (disponibilizado pela Improve It nos próximos dias).

O assunto será RSpec e RSpec on Rails novamente, mas dessa vez terei mais tempo para me apresentar.

Nos vemos por lá!

Acredito que os eventos serão bastante divertidos e informativos e espero que ninguém durma de tédio nas minhas apresentações :-). Faça sua inscrição e deixe um alô nos comentários para saber se devo te encontrar por lá!

Na reunião do Dojo@SP do último dia 03/Out decidimos gravar um screencast do Kata que estávamos resolvendo: Splitting the Loot. Nessa reunião, eu apresentei um Kata Preparado, programando em Ruby e utilizando RSpec+RBehave como frameworks de BDD. O resultado está finalmente disponível no Google Video:

Depois da conversão, a qualidade do vídeo acabou sendo prejudicada. No tamanho original dá pra assistir, mas as letras ficam pequenas (principalmente quando mudo pro terminal). Os atalhos de teclado (gravados com o KeyCastr) também ficam ruim de ver.

Para assistir uma versão com resolução melhor, disponibilizei o arquivo original para download no site da AgilCoop:

• Dojo@SP Screencast #01 (1h33min / 266Mb)

O código final dessa e de todas as nossas reuniões pode ser obtido no nosso Google Groups.

Gostaria de agradecer a Mariana Bravo por ter criado nosso logotipo, o Paulo Sacramento, por ceder a música Batida Urbana sob a licença Creative Commons – Atribuição-Uso Não-Comercial 2.5 Brasil (utilizada na introdução e no final do vídeo) e aos participantes da reunião pelo feedback e ajuda na resolução do problema: Breno Franco, Daniel Cordeiro, RBP e Thiago Colucci.

Espero que esse vídeo ajude a mostrar como o Dojo funciona. O feedback de vocês é muito importante. Caso o retorno seja positivo, podemos produzir outros vídeos semelhantes. Se você se interessou pelo Dojo@SP, junte-se a nós!

Acabei de ler um post do Uncle Bob que tem tudo a ver com meu último post. Um trecho interessante que ele diz é:

Acceptance tests should be written at the start of each iteration. QA and Business analysts should take the stories chosen during the planning meeting, and turn them into automated acceptance tests written in FitNesse, or Selenium or some other appropriate automation tool.




The first few acceptance tests should arrive within a day of the planning meeting. More should arrive each day thereafter. They should all be complete by the midpoint of the iteration…

Numa tradução livre:

Testes de aceitação devem ser escritos no início de cada iteração. QA e os analistas de negócio devem pegar as histórias escolhidas na reunião de planejamento e torná-las em testes de aceitação automatizados escritos no FitNesse, Selenium ou outra ferramenta de automação apropriada.




Os primeiros testes devem chegar no dia seguinte ao planejamento. Mais testes devem aparecer nos próximos dias. Eles devem estar completos até a metade da iteração…

Apesar de já concordar com o conteúdo, ele me fez repensar algumas coisas. Como já disse anteriormente, testadores e responsáveis por QA ficam de boca aberta quando digo que o departamento deles não deve existir. Incluo minha irmã nesse grupo, que trabalha no controle de qualidade de um indústria química :-)

O que o Uncle Bob me fez pensar foi que os testes devem aparecer conforme são necessários. É a filosofia Just-in-Time da Toyota aplicada aos testes. Se você escreve os testes (de unidade ou de aceitação) pouco antes de serem necessários você:

• Evita desperdício escrevendo documentos de casos de teste ou pensando nos cenários mais elaborados do mundo. Seu foco está na pergunta: “Como sei se esta história está terminada?”.
• Evita a formação de um estoque de código sem teste (sistema pull e não push).
• Usa o teste para pensar no design do que está construindo.
• Cria um script automatizado que serve como documentação e ajudará os desenvolvedores que precisarão mexer no seu código futuramente (Benefício Mútuo).

Acho que a partir de agora vou mudar meu discurso. Ao invés de dizer que o departamento de qualidade deve ser extinguido, vou dizer que QA deve ser Lean, Just-in-Time. Acho que essa vai ser uma abordagem mais inclusiva e vai gerar menos confronto. O que você acha?

Muitas equipes XP não automatizam seus testes de aceitação. Essa é uma afirmação dura, porém muito comum de acontecer. A equipe abraça TDD e testes de unidade automatizados, porém quando chega a hora dos testes de aceitação, a coisa complica. Por que isso acontece? Como melhorar essa situação?




Nesse post, inspirado por uma pergunta na XP@Rio, espero dar algumas dicas para ajudar quem tenha se identificado com minha alfinetada. :-)

O que é Teste de Aceitação?

Em primeiro lugar, é bom deixar claro qual a visão Ágil sobre testes. XP, em particular, pede que sejam escritos dois tipos de testes automatizados:

• Testes de Unidade: testes do programador. Geralmente testa um pedaço isolado do código. Quando seguimos TDD, o teste é escrito antes do código e funciona como especificação, te ajudando a pensar no design. Depois de escrito, serve como documentação executável do seu código.
• Testes de Aceitação: testes do cliente. Um teste de aceitação (ou Story Test, ou Customer Test) descreve um cenário (de sucesso ou não) com uma expectativa do cliente em relação à história ou funcionalidade. Como o nome sugere, ele ajuda a equipe a entender quando uma história está completa (aceita).

Um pequeno adendo: apesar de ser importante reconhecer esses dois tipos de teste propostos por XP, existem outros tipos de teste igualmente importantes como: testes funcionais, de interação, de carga, de segurança, etc… Isso varia conforme sua situação particular, mas esse não é o assunto desse post :-)

Algumas desculpas

Como disse no início do post, muitas equipes deixam de automatizar seus testes de aceitação. Existem muitas justificativas para explicar esse fato:

• Automatizar testes de aceitação é difícil: Testar um sistema web do ponto de vista do usuário ficou muito mais fácil atualmente com ferramentas como o Selenium ou Watir. Testar uma interface gráfica Swing é um pouco mais chato porém não impossível. Testar um software que gera imagens ou modelos visuais (um CAD como o Archimedes, por exemplo) é bem mais difícil. Testar um sistema embarcado depende do hardware. Testar um jogo depende de um jogador (automatizar o jogador pode não ser tão fácil). E por aí vai… dependendo da sua situação, tenho que concordar que sua tarefa pode não ser tão fácil. Mas qual a graça de programar sem desafios? :-)
• O teste fica muito grande: Para testar um cenário, geralmente é preciso fazer muito setUp. Você vai precisar criar diversos objetos, suas associações e terá que se preocupar em apagá-los depois (para manter a independência entre os testes e entre diferentes execuções do mesmo teste). Isso pode gerar problemas de dependência e você passa a perder mais tempo fazendo setUp e tearDown do que efetivamente escrevendo os testes importantes.
• O teste demora muito: O problema anterior faz com que seu teste demore muito para executar. Muitas vezes você pode depender de um banco de dados ou de outro sistema para testar um cenário de aceitação real. Se utiliza um sistema de Integração Contínua, perceberá rapidamente que seus ciclos de build demoram muito mais.
• O cliente não sabe escrever testes: É muito mais fácil um programador aprender a usar o JUnit ou qualquer framework do que o cliente. É papel da equipe encontrar a melhor forma de comunicação com o cliente. Se o cliente trabalha num banco, tente usar uma planilha ou uma tabela. Se seu sistema é cheio de regras de negócio complicadas, tente explorar os diferentes cenários pensando em exemplos. Infelizmente, não existe uma estratégia universal.

Alguns desses problemas são mais difíceis que outros. Mas de que adianta falar mal e enumerar problemas sem dar idéias de soluções?

Sugestões para melhorar a situação

Um novo papel

Quando falo que a Toyota eliminou o departamento de qualidade e teve ganhos incríveis de produtividade, geralmente recebo olhares espantados e desconfiados, principalmente da equipe de testes. “Você está dizendo que devo ser demitido?”. Calma, não é bem assim. A Toyota não eliminou sua preocupação com qualidade. Pelo contrário, ela valoriza tanto esse aspecto que compartilhou essa responsabilidade com TODOS os envolvidos no processo. Não quero que os testadores sejam mandados embora. Pelo contrário, suas habilidades devem ser espalhadas e aproveitadas por todo o processo de desenvolvimento. Devem trabalhar muito mais próximos e não no final da cadeia. Shigueo Shingo já dizia: “Inspecionar para procurar defeitos é desperdício. Inspecionar para previnir defeitos é essencial”.

O papel do testador numa equipe ágil é tão importante quanto o do programador. Ele ajuda a equipe e o cliente a aprimorar suas estratégias de teste (principalmente de aceitação). Eles fazem parte da equipe e também são responsáveis pela entrega! Lembrem-se: a história não está pronta enquanto não estiver testada!

Reaproveitando uma estratégia conhecida

Eu citei os maiores benefícios dos testes de unidade e TDD: eles te ajudam antes, durante e depois. Antes, te ajudam a especificar o problema e pensar no design do código. Durante, eles servem como rede de segurança, identificando um bug de regressão assim que ele é inserido e dando suporte à refatoração sem medo. Depois, servem como documentação executável do seu código, auxiliando você a dar manutenção e novos integrantes a entender o que o sistema faz.

Esses mesmos benefícios se aplicam aos testes de aceitação! O Kent Beck percebeu essa Auto Semelhança na segunda edição do livro de XP. A prática conhecida como Story Test Driven Development (ou STDD) funciona exatamente como TDD, porém no nível das histórias. Eu comentei sobre essa prática num post anterior da XP2007.

O cliente deve colaborar com a equipe para enumerar os cenários de aceitação. Pense em exemplos. Uma pergunta que te ajuda a definir tais cenários é: “Como saberei que terminei essa história?”. Se seu cliente não sabe ou não quer definir os cenários de aceitação, apenas responda: “Pronta!”. Os testes de aceitação te ajudam a saber quando a história está pronta. Se o cliente não define nenhum cenário de aceitação, a história está automaticamente pronta (inclusive testada!!). :-)

Ferramentas

Diversas ferramentas e frameworks têm surgido para auxiliar sua vida. Como já disse anteriormente, o Selenium e o Watir podem facilitar sua vida no teste de aplicações web. O FIT, que já comentei algumas vezes aqui, também te ajuda a sair do lado técnico e define uma linguagem de comunicação mais simples com o cliente (através de tabelas de exemplo). O Fitnesse armazena essas tabelas (e outras informações) num wiki.

Um framework que atraiu bastante minha atenção ultimamente foi o RBehave. Atualmente ele está sendo incorporado ao RSpec, um framework bem conhecido para BDD em Ruby (e Rails, mais recentemente). O assunto teve até um tutorial na última RailsConf na Europa. Ele te permite escrever cenários de aceitação da história de forma executável. Vale a pena dar uma olhada. Tem a versão Java também: jBehave.

Apesar de ter escrito muito, acredito ter apenas arranhado a superfície desse assunto tão interessante e tão amplo. Para um pouco mais de informações, sugiro ouvir o AgilCast #9 e assistir alguns dos nossos AgilVídeos.

Também gostaria de saber: O que você programa/desenvolve? Qual sua estratégia para automatização dos testes de aceitação? O que de legal você fez em relação ao assunto? Qual sua maior dificuldade?