Red, Green, Refactor?
Author: Jonas Abreu24 Mar
Já faz um bom tempo que eu mudei o meu ciclo de desenvolvimento com testes do Red, Green, Refactor (ciclo tradicional de TDD) para algo um pouco diferente.
O que aconteceu foi que eu tinha muito problema para pensar nas unidades pequenas sem ter as unidades grandes. Ah? Basicamente eu não consigo pensar em como implementar sem estar resolvendo o problema.
Confuso ainda, certo?
Bom, digamos que eu queira implementar algo que transforme um html em uma árvore (basicamente, parsear html). Eu não consigo pensar em como eu faria para parsear a tag. Apenas consigo pensar em como funcionaria para o html. Algo como:
HtmlParseado html = new HtmlParser().
parse("<html><title>Conteudo</title></html>");
Somente no momento em que estou dentro do método parse que eu consigo pensar em como descobrir quais são as tags. Por que isso? Por causa da abstração.
No código acima não faz o menor sentido pensar nas tags, apenas no html completo. Dentro do método parse começa a fazer sentido procurar pelas tags.
Então o que tenho feito? Eu crio um ou mais testes que sobre a funcionalidade inteira (no caso, o que o parse deve fazer com o html).
Algo como:
@Test
public void testaQueOParserFunciona(){
HtmlParseado html = new HtmlParser().
parse("<html><title>Conteudo</title></html>");
Assert.assertEquals("html", html.getFirstChild().getTagName());
...
}
O problema é que esse teste é muito grande para guiar o desenvolvimento. O que eu faço então? Parto para o problema menor que é o reconhecimento de tags.
Como nesse ponto eu já consigo imaginar mais ou menos o que quero que aconteça, consigo criar os testes para fazer o reconhecimento de tags.
Mas durante todo esse tempo, o meu teste do ponto mais alto da abstração continua sem passar. Isso quebra com o RGR, mas me ajuda muito com o desenvolvimento da interface de uso.
Talvez eu tenha perdido um pouco na qualidade do código usando essa abordagem top-down, mas ganho bastante em termos de usabilidade desse código. Isso me força a pensar em primeiro lugar em como vai ser usada a funcionalidade final e não nos menores constituintes dela.
Outra coisa que esses testes me ajudam muito é a saber quando eu terminei a funcionalidade mais complexa.
O que acham disso? Já fizeram (ou fazem) algo semelhante?
Posts Relacionados:
Acompanhe-nos por
RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.
Screencast do Coding Dojo
Author: convidados6 Feb
O Bruno Pedroso publicou hoje um screencast do Coding Dojo - evento que ocorre em diversas cidades do país para desenvolver técnicas de Test Driven Development (TDD).
CodingDojo SEA - Crosswords por Bruno Pedroso no Vimeo.
Este é apenas um trecho do evento, mas serve para demonstrar as técnicas utilizadas. Em São Paulo, o evento atualmente ocorre às segundas-feiras às 20hrs no Instituto de Matemática e Estatística da Universidade da Universidade de São Paulo, é gratuito (leve dinheiro para rachar uma pizza se quiser jantar por lá) e aberto a todos os interessados.
Mais informações podem ser obtidas no site oficial do Coding Dojo São Paulo e através da lista de discussão.
Posts Relacionados:
Acompanhe-nos por
RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.
FISL 9.0: Coding Dojo
Author: Cecilia Fernandes19 Apr
A palestra, não exatamente num formato normal, começou com uma votação sobre a linguagem (Ruby, Phyton ou Java) seguido de uma breve explicação sobre o Dojo.
Dos objetivos do dojo, passando por princípios como uso de TDD (test driven development) e não deixar sobrar dúvidas e com uma breve explicação sobre os dois estilos de dojo: Kata e Randori. Utilizaram, então, o Randori:
dojo.epistemol.net
Turnos de 5 a 7 minutos em pair programming. Quando troca, o programador em si sai e alguém da plateia entra como “co-piloto”. A platéia deve ficar em silêncio enquantos os testes não estiverem passando e podem comentar e criticar o código quando os testes passam. Além disso, se a dupla de programadores estiver completamente perdida, pode pedir ajuda da platéia.
Então, uma nova votação definiu o problema a ser resolvido: resolveríamos o problema Roman Numbers em Java. Após alguns problemas com o Eclipse e a JRE recém-instalada, começamos os turnos.
Definitivamente em baby-steps, começamos a implementação dos testes e do método conversor minimal para cada teste. Quando chegamos a 1:30 de palestras, foram passados cartões para que a platéia apontasse pontos positivos e negativos do Dojo e a retrospectiva completa e discutida deve estar em breve no site dojo.epistemol.net.
Algumas perguntas particularmente relevantes surgiram, também:
- Quantas pessoas no máximo participam de um Dojo?
Tantas quantas forem possíveis mantendo o foco do grupo e o aprendizado. Quantos mais pessoas, menos o grupo, como um todo, aprende.
- Como são escolhidos os problemas para o Dojo?
Normalmente, pega-se problemas prontos como em ACM-UVA arbitrariamente, de acordo com o grupo.
E também uma observação interessante:
“Em vivência acadêmica, temos contato com a maratona de programação, onde o foco é resolver rapidamente e sem se preocupar com beleza de código. O Dojo vai exatamente pelo lado contrário, se preocupando com a beleza do código e os testes e não com o tempo gasto ou com a completude do problema.”
Desculpe a citação não literal, mas acho que passei a idéia corretamente.
Posts Relacionados:
Acompanhe-nos por
RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.
