TFD ? TDD ? BDD ?
- TFD - Test-First Development
- TDD - Test-Driven Development
- BDD - Behavior-Driven Development
Qualquer destas siglas, representa basicamente a metodologia de começar o desenvolvimento, não pelo código da funcionalidade propriamente dito, mas sim pela codificação dos testes (ou comportamentos) que vão garantir que a funcionalidade codificada faz o que dela se espera.
É como se a codificação dos testes (ou comportamentos) representasse a especificação em código da funcionalidade. E a codificação da funcionalidade vai então atender exatamente a especificação. Simples assim!
No nosso caso, vamos escrever nosso método de teste unitário antes de escrever o método sendo testado. O Eclipse possui um excelente suporte ao uso de TDD.
O método toString()
Nossa próxima tarefa vai ser sobrepor o método "toString". Vamos revisar algumas de suas características:
- Ele é herdado da Classe Object
- Ele retorna a representação em String de um Objeto
- Ele é normalmente criado para todas as Classes
Vamos voltar à nossa página de Scrapbook e ver o que este método faz:
Preparando o código assim:
Que uma vez inspecionado, nos apresenta o seguinte:
Reparem que a nossa Classe Pessoa, está ali identificada (id=47). Mas de forma geral, estas informações não são muito úteis. Isso se dá, porque este método é herdado da Classe Object, e a Classe Object não "conhece" nada sobre a nossa Classe Pessoa.
Em geral, quando criamos uma nova Classe, gostaríamos de modificar o método "toString" para melhor representar os objetos da nossa Classe.
O que vamos fazer, é chamado de "Override" de método, ou seja, vamos "escrever por cima" de um método já existente. Não estaremos criando um método novo, mas sim aplicando um novo comportamento à um método já existente que a nossa Classe está herdando de Outra.
Aplicando o TDD
Neste ponto, poderíamos simplesmente abrir a nossa Classe Pessoa e começar a escrever código novo. No entanto, vamos aplicar a metodologia de TDD, e para isso, vamos recapitular o que esta metodologia propõe:
- Pense sobre o que o método deve fazer.
- Escreva um caso de teste que vai testar este método.
- Escreva o novo método.
- Teste o novo método.
- Quando o teste passar, teremos concluído.
De volta à nossa Classe de teste, vamos escrever um método para testar a nossa versão do método "toString". Mas cumprindo o item 1 da metodologia, vamos pensar em: qual o comportamento desejado para "o nosso" método "toString" ?
1 - Um objetivo prático, seria que o nosso método "toString" retornasse o nome e o número de livros de uma determinada pessoa da seguinte forma:
Romer Simpson (9 livros)
2 - Vamos escrever um caso de teste para isso na Classe "PessoaTest". Estaremos usando as facilidades já vistas anteriormente, obtendo o seguinte resultado:
Este método por si só, serve como documentação do nosso método "toString". Se alguém alterar o comportamento do nosso método "toString" e esquecer de alterar este teste, ele vai falhar, indicando que a documentação não está mais em conformidade com a implementação.
3 - Vamos agora escrever a nossa versão do método "toString"na Classe "Pessoa". Estaremos mais uma vez usando as facilidades já vistas anteriormente, obtendo o seguinte resultado:
Ao salvar as alterações, é exibida uma tela de alerta indicando que uma parte do código em memória não pode ser atualizado, assim:
Isso ocorre porque o Scrapbook usa o modo Debug do Eclipse, e neste modo as alterações feitas no código quando salvas, não substituem automaticamente o que está em memória.
4 - O próximo passo, é executar os testes e ver o que acontece.
Acionando o botão de comparação dos resultados, podemos ver o seguinte:
Fica claro que não definimos corretamente o retorno do método.
5 - A última etapa é na verdade, um ciclo, onde refatoramos o método até que o teste passe. Vamos corrigir o retorno do método, ficando assim:
Testando novamente, teremos o seguinte:
Todos os testes passaram, e era isso que pretendíamos. Observem que existe um alerta na Classe Pessoa, indicando que o nosso método "toString" se sobrepõe ao método original, assim:
Fazer uso diretamente dos nomes dos atributos no lugar dos respectivos métodos get, desta forma:
Pode nos causar restrições no futuro. Imaginem a seguinte situação: alguém resolve separar o atributo nome nos atributos primeiroNome e sobreNome.
Da forma que fizemos, isso iria requerer uma alteração no nosso método toString da Classe Pessoa. Já se tivéssemos usado os métodos get desta forma:
Bastaria alterar o método "getNome" para:
return primeiroNome + " " + sobreNome;
Mantendo nosso método toString livre de alterações.
Vamos portanto, preferir sempre o uso dos métodos get evitando alterações desnecessárias em métodos que façam uso direto dos nomes dos atributos.
Nenhum comentário:
Postar um comentário