Danilo Sato

Você já ouviu falar em Desenvolvimento Orientado a Testes (ou TDD)? Já escreveu testes antes do código? Esta é a primera parte de uma série onde aplicaremos as idéias de TDD num exemplo prático, desenvolvendo um clássico jogo de tabuleiro que não depende da sorte, mas sim da estratégia: Combate.

Introdução

Conforme eu adiantei no último post, começaremos hoje um exemplo de aplicação de TDD num exemplo prático. Essa idéia começou quando um colega de trabalho, Rodrigo (mais conhecido como RBP ou simplesmente R), sugeriu fazermos uma rápida sessão de Programação Pareada, para que eu mostrasse na prática como programar os testes antes do código. Desde então, discutimos alguns problemas simples, porém interessantes (e por que não divertidos?), que poderíamos utilizar no nosso exemplo, chegando ao clássico jogo de tabuleiro Combate.

Seguindo o exemplo de Ron Jeffries de ensinar TDD através de exemplos (desenvolvendo um programa para calcular o total de pontos em uma partida de boliche), começaremos hoje falando sobre os princípios de TDD e sobre as regras do Combate. Ainda na linha experimental e educativa dessa série de posts, vou aproveitar os conhecimentos do RBP e aprenderei um pouco de Python. Ainda não sabemos quantos posts serão necessários e nem se estamos sendo ambiciosos demais, porém nossa idéia é mostrar o crescimento incremental da aplicação, podendo até se transformar em algo “jogável” (com interface gráfica e funcionando em rede).

Regras do jogo: TDD – Test Driven Development

O Desenvolvimento Orientado a Testes é uma técnica para programadores (e não para testadores), cujo objetivo é a melhoria contínua do design. Essa técnica é fortemente baseada em testes automatizados, que são escritos antes do código, influenciando e orientando o design e a divisão das responsabilidades entre as classes do sistema. Dessa forma sua aplicação evolui em passos pequenos construindo apenas o design necessário para atender aos requisitos atuais do sistema. Como efeito colateral, você acaba desenvolvendo uma bateria de testes automatizados que pode ser executada a qualquer momento e que funciona como uma rede de proteção na hora em que as mudanças começarem a aparecer (e elas irão aparecer).

Quando desenvolvo com TDD, me vejo muito mais preocupado com decisões de design do que quando utilizo uma abordagem diferente para codificação. Ao escrever os testes do ponto de vista de um cliente da classe em questão, as preocupações com encapsulamento, divisão de responsabilidade e colaboração entre as classes se fazer muito mais presentes. Além disso, ao contrário do que possa parecer, desenvolver os testes junto com o código traz um aumento na produtividade, pois evita desperdícios futuros com depuração, reduz riscos durante a integração e melhora o design geral da aplicação, investindo somente o necessário um pouco antes e um pouco depois da implementação (evitando generalizações desnecessárias).

O Densenvolvimento Orientado a Testes impõe um ritmo constante e incremental baseado em passos pequenos. O passo inicial é pensar um pouco sobre o que será desenvolvido e elaborar uma pequena lista dos testes que serão implementados. O ritmo de TDD pode ser resumido num ciclo de iterações com os seguintes passos principais:

1. Vermelho – Escreva um teste que falha (execute-o e veja falhar, para garantir que estará implementando algo relevante)
2. Verde – Rapidamente, faça o teste passar (Escreva apenas o código necessário para que o teste passe, lembre-se: não se preocupe com o que você não vai precisar)
3. Refatore – Refatore para eliminar duplicação e aumentar a expressividade do código. Evolua em direção ao design simples, reduzindo o acoplamento e aumentando a coesão.

Por fim, algumas recomendações: nunca escreva mais de um teste por vez e nunca refatore no vermelho.

Regras do Jogo: Combate

Combate (ou Stratego) é um jogo de estratégia, jogado num tabuleiro de 10×10 entre 2 jogadores, cada um com 40 peças representando os oficiais de um exército (e suas respectivas patentes). As peças são posicionadas de qualquer forma nas primeiras 4 fileiras de cada jogador, de forma que o adversário não saiba distinguir o valor de cada peça. O objetivo do jogo é capturar a bandeira do adversário ou deixá-lo com tão poucas peças que não possa se mover no tabuleiro.

Cada jogador move uma peça no seu turno (tanto na horizontal quanto na vertical). Todas as peças, com exceção dos soldados, só podem se mover 1 quadrado por vez. Se uma peça é movida para um espaço ocupado pelo adversário, suas patentes são reveladas e a mais fraca é removida do tabuleiro. Em caso de empate, ambas as peças são removidas. O valor numérico determina o vencedor na maioria dos casos, porém existem peças especiais: as bombas (não se movem e eliminam qualquer outra peça, exceto o cabo-armeiro), a bandeira (não se move) e o espião (a única peça que vence quando ataca o marechal, porém perde para qualquer peça que o atacar, incluindo o próprio marechal).

A quantidade de peças de cada jogador, em ordem de patente (da mais forte para a mais fraca), é:

No ISF (International Stratego Federation) você encontra as regras oficiais do jogo.

A seguir…

No próximo post, iniciaremos a implementação da engine do jogo. Nossa idéia é desenvolver o jogo de forma incremental, então pensamos nos seguintes passos (lembrem-se, um plano não é um comprometimento sobre o que irá acontecer. Mudanças são bem-vindas!):

1. Regras de ataque e de movimentação
2. Controle do estado do jogo e das rodadas
3. Gerenciar posicionamento inicial das peças
4. Desenvolver uma interface textual
5. Desenvolver uma interface gráfica
6. Cliente/Servidor para jogar em rede