Um post sobre o uso de baby steps em dojos, escrito pelo Mauricio Aniche, tem causado discussao. Eu escrevi sobre baby steps ha algum tempo e concordo em genero, numero e grau com o post, mas ha um ponto que ainda nao vi ser tocado na comunidade.Eu tenho observado ha alguns meses que algumas praticas do dojo andam meio que passando uma visao incorreta sobre TDD, e nao e so por causa das cascatas de ifs. Nada melhor que exemplos para mostrar o que quero dizer. Em TDD/BDD/whatever no mundo real, ninguem vai escrever um teste:it 'dois mais dois e igual a quatro' do ...endoudef test_quatro_nao_e_um_numero_feliz(self): ...Nestes codigos, o nome do metodo e a expectativa. Em TDD, uma expectativa, e o resultado que se espera que ocorra na execucao do teste, seja uma expectativa padrao como order.clear |should| change(order.item_count).by(-3) ou uma verificacao de mock como MailService.should_receive(:send).with("sos@batcave.com").O nome do metodo de teste (ou a sua descricao, no caso do RSpec) nao e e nem pode ser a expectativa, pelo menos a se julgar pela literatura de TDD. O nome do metodo de teste e o nome de uma responsabilidade da classe (o "test method names should be sentences" que e tao enfatizado em BDD).O correto seria:it 'soma dois numeros' do ...endoudef test_identifica_numeros_infelizes(self): ...Em todos os casos, o nome dos metodos e uma descricao abstrata - no sentido de nao trazer exemplos concretos - e as expectativas com seus valores objetivamente verificaveis vem no interior dos metodos de teste. Ou seja, em TDD, cada metodo de teste representa algo que a classe e capaz de fazer e nao infinitas variacoes de valores passados a uma mesma funcionalidade. No fim das contas, a expectativa acaba sendo escrita duas vezes: uma vez no nome do metodo e outra na expectativa propriamente dita. A questao aqui nao e o uso ou nao de baby steps, mas uma formulacao de testes que e conceitualmente diferente daquela utilizada na literatura de TDD.Veja um exemplo, do livro "Growing Object-Oriented Software, Guided By Tests", de Steve Freeman e Nat Pryce (Addison-Wesley, 2009):public class CatalogTest { private final Catalog catalog = new Catalog(); @Test public void containsAnAddedEntry() { Entry entry = new Entry("fish", "chips"); catalog.add(entry); assertTrue(catalog.contains(entry)); } @Test public void indexesEntriesByName() { Entry entry = new Entry("fish", "chips"); catalog.add(entry); assertEquals(entry, catalog.entryFor("fish")); assertNull(catalog.entryFor("missing name")); }}Neste codigo, os testes sao:- contains an added entry- indexes entries by nameOu seja, sao responsabilidades abstratas e nao exemplos concretos.Kent Beck, em seu classico "Test-Driven Development By Example" (Addison-Wesley, 2003), vai na mesma linha: seus testes na classe Money que foi citada no post se chamam "multiplication", "equality", "currency". Ou seja, nada de "twoDollarsPlusThreeDollarsEqualFiveDollars".Outra referencia de TDD que gosto bastante, "Test Driven: TDD and Acceptance TDD for Java Developers", de Lasse Koskela (Manning, 2007), tambem segue a mesma ideia. Este livro, por sinal, tem disponiblizado o segundo capitulo para download, contendo um excelente exemplo de baby steps que vale mesmo a pena ser lido. Neste exemplo, novamente, os testes sao "unknownVariablesAreIgnored", "multipleVariables" ou "missingValueRaisesException". Novamente, nada de expectativas nos nomes dos testes.Certamente, nao ha "culpados" por isto, e