TDD e infraestrutura

Assuntos Gerais Agile
#1

Pessoal,

Estou começando meus estudos sobre TDD (caso fale alguma bobagem por favor me corrijam) e estou achando muito interessante, principalmente por focar no domínio.

Mas tenho dúvidas.

Com relação a descobrir classes de domínio durante a criação dos testes:
Em alguns projetos que trabalho que são suporte para o negócio principal não consigo enxergar como aplicar TDD pois se tratam de coisas muito relacionadas a estrutura tecnológica como envio/recebimento de arquivos . Essas operações tem um série de procedimentos e checagens e o código fica muito emaranhado, como eu aplicaria TDD nesses casos?

Com relação aos testes em si:
Pelo que pude entender os testes são feitos na menores funcionalidades possíveis, mas como eu poderia testar operações do tipo conectar com servidor FTP , verificar se arquivo existem , verificar se a copia foi bem sucedida, enfim operações de infraestrutura?

#2

[quote=luiz_renato]Pessoal,

Estou começando meus estudos sobre TDD (caso fale alguma bobagem por favor me corrijam) e estou achando muito interessante, principalmente por focar no domínio.

Mas tenho dúvidas.

Com relação a descobrir classes de domínio durante a criação dos testes:
Em alguns projetos que trabalho que são suporte para o negócio principal não consigo enxergar como aplicar TDD pois se tratam de coisas muito relacionadas a estrutura tecnológica como envio/recebimento de arquivos . Essas operações tem um série de procedimentos e checagens e o código fica muito emaranhado, como eu aplicaria TDD nesses casos?
[/quote]
O problema esta no codigo emaranhado, tente separar o que eh conexao para envio e recebimento de arquivo daquilo que eh tratamento das regras de negocio que vao operar sobre as informacoes que serao gravadas nesse arquivo.

Supondo que voce tenha:

public void geraArquivo(){
   if (isso) fazAquilo();
   gravaNoArquivo();
   validaMaisIssoIssoEAquilo();
   gravaNoArquivo();
   while (naoSeiOQue){
     incrementaAlgumValor();
     gravaNoArquivo();
   }
}

Separe o que for validacao, escreva testes para a validacao, so depois que estiver com tudo pronto comece a gravar o arquivo. Assim voce separa e consegue testar.

Voce nao precisa testar o servidor FTP, voce assume que ele funciona, afinal ele eh um agente externo ao seu sistema e deve funcionar. O que voce vai ter que testar eh o que vai acontecer com o seu sistema, caso algo de errado aconteca com o FTP. Por exemplo, testeSeGeraMensagemDeErroSePerderConexaoComServidorFTP().

Ai voce mocka as chamadas ao servidor real e testa as possiveis falhas, determinando como sua aplicacao vai reagir caso elas acontecam.

A API do java de gravacao de arquivos funciona, voce nao precisa testa-la, voce vai ter que testar se os dados estao sendo enviados para o arquivo no formato correto e o que vai acontecer caso um diretorio esperado nao exista, ou haja algum problema na gravacao do arquivo. Mais uma vez voce usa mocks para ver como a sua aplicacao reage a possiveis erros. Nao adianta testar o java.io.

Depois sim, voce pode escrever testes de integracao para conexao com o servidor real e testes de escrita e leitura de arquivos reais. Mas testes de integracao sao diferentes de testes unitarios.

Vale lembrar que TDD, apesar de parecer muito simples a principio, eh muito complexo, muito dificil e leva um bom tempo ate que voce consiga se entender com ele, entao nao desanime se as coisas nao se resolverem como magica (como eh pregado por ai sobre TDD) ja de cara. O caminho do aprendizado eh longo, mas compensa.

#3

realmente o que o YvGa falou faz todo sentindo. e para completar, vc não vai achar toda solução com TDD. eu costumo dizer, que TDD é abstract e que depende de nos desenvolvedores saber onde devemos encaixar e onde ele é eficiente. Nem sempre será e vc vai descobrir isso a medida que programa mais usando a tecnica e entende onde TDD causa efeitos positivos ou não. Enfim, não tem receita de bolo para TDD, refactoring. É estudar o contexto e ir avançando e ver onde vai dar. Eu recomendo o livro do Kent Beck, é um livro bem abstract, para quem já usa TDD vai aprender a experiencia dele e ter uma visão bem legal da técnica. No meu proximo livro que devo lançar no meio do ano, falarei da minha experiencia com TDD e cenários que devemos atacar pelo qual passei e tb aqueles que não deu para usar TDD de fato.

flw.

#4