[quote=sergiotaborda][quote=YvGa][quote=sergiotaborda]
Pensando de outa forma, no modelo padrão vc quer colocar um pattern X vc vai e coloca. Em TDD vc não faz isso. Vc escreve um código qualquer e depois quando for refactorar é que vc identifica o padrão e o usa. O TDD é reactivo e não pro-activo. E isso pode ser bom quando vc quer ser minimalista como o Beck gosta de ser, mas implica em muitos passos desncessários. Ai ele fala que a pessoa pode pular para o passo que deseja ( no caso, pode colocar o padrão logo de inicio). Mas isso para mim não é desenvolvimento assistido, é simplesmente ter uma ideia e colocar um teste à volta dela (Test First).[/quote]
Certo, Sergio, entendo seu ponto de vista, mas deixa eu fazer uma defesa ao Beck, ou uma acusação, já que o livro dele não deixa isso claro. Mas foi a maneira que eu sempre entendi, lendo principalmente ele e os outros dois autores que eu citei no meu post anterior.
Não existe um jeito certo de começar a implementação, você pode começar por onde quiser, outside-in ou inside-out (o que pra mim parece o mesmo que top-down ou bottom up), você pode desenhar primeiro a interface de uma calculadora, pode implementar as teclas com infra-estrutura fake e ir aos poucos descendo para as operacoes matematicas. Ou então você pode fazer inside-out, começar pelas operações e vir para as teclas e a interface depois.
Mas o que você não pode, nem vai conseguir, de jeito nenhum, e é o que parece muita gente ter entendido da proposta do TDD é planejar inside-out. Não se pode planejar inside-out, não é possível imaginar uma calculadora começando simplesmente pelas operações matemáticas, sem pensar em como um ser humano irá interagir com ela
[/quote]
Aqui que vc se engana. A definição do dominio não depende da interação. Uma calculadora não é o que vc vê na tela, são as regras colocadas no codigo. Vc pode usar essas mesmas regras e colocar num servidor com um webservice na frente. Não ha necessidade de interação com o ser humano para definir o dominio. Isto é DDD. O Dominio é o ponto de partida porque é ele que atente dos requisitos que os usuários pedem. O resto é decoração e UX. Mas se o dominio não está bem modelado, não ha UX que salve.
Eu sim posso somar dois numeros sem saber se são float ou double ou int. Vc cria uma abstração. Vc pode criar uma classe com operação de soma e subtração que produzem objetos da mesma classe, e nunca, por baixo dos panos realmente fazer nenhuma conta. Mas vc abstraio o conceito de “operação” e é isso que é seu dominio.
Em nenhum momento eu falei de planejamento. Eu falei de design. Design não é planejamento, ele já é o produto final. Planejar o design é algo impossivel. Ou vc realiza o design ou não realiza. Vc pode realizar e se arrepender, mas não pode evitá-lo.
Frases como “Daqui a um mes implementamos o serviço de conversão” já implica que o design foi feito e existe um tal de “serviço de conversão”.
TDD realmente não tem que ver com planejamento, pois não é uma disciplina de gerencia.
[/quote]
Acho que estamos falando a mesma coisa de jeitos diferentes. Ok, vc acha que é possivel ter a funcionalidade de soma da calculadora, sem a interface humana e etc, etc, etc. Mas o ponto em que eu queria chegar é que voce não consegue planejar inside-out ou outside-in, voce necessariamente precisa da visão do todo antes de implementar. Mas visao nao eh ter o todo detalhado, minuciosamente descrito, visão do todo é simplesmente a visão, existem N possibilidades da implementação dessa visão e o TDD vai te ajudar a caminhar por elas.
Só quanto ao “voce não pode planejar o design” que talvez eu não concorde, ou talvez não tenha entendido. Essa visão do todo é um planejamento do design. Eu digo para um companheiro: “que tal se fizermos com que o pedido possua uma lista de itens e interaja com os produtos da seguinte maneira:…” Isto é planejamento de design. Depois eu vou implementar isso e ver se está de acordo.
De resto acho que estamos dizendo a mesma coisa de jeitos diferentes, sobre planejamento-implementação