Estou usando o commons-lang para implementar equals, hashcode e toString… quebra um bom galho!
Testar o equals é chato pacas, mas em testes de outras funcionalidades do sistema, sabendo que o equals foi devidamente testado acaba valendo a pena!
Eu crei um testSaveAndLoad…
Daí eu salvava o objeto, buscava ele de volta, mas daí pra saber se tinha retornado objeto correto ttinha que ficar testando atributo por atributo… daí não dá né!!!
“testSaveAndLoad” eh um nome ruim - tente algo do tipo “test Projects Can Be Saved And Loaded Without Losing Any Attribute Data”, ou testProjectsCanBeSavedAndLoadedWithoutLosingAnyAttributeData(), pros intimos. Voce nunca vai ter que chamar esse metodo mesmo, pq nao dar um nome extremamente explicativo pra ele?
Bom… primeiro eu comecei a me interar sobre Extreme Programming! É interessante vc ter idéia de como funciona uma metodologia de desenvolvimento ágil. Existem vários livro sobre este assunto, mas eu li o Extreme Programming do Vinicius Manhães Teles:
Este livro aborda a criação de uma aplicação PetStore usando apenas tecnologias open source. Mas o que é interessante no livro não são apenas as tecnologias abordadas, mas sim o fato do desenvolvimento deste projeto ser guiado por testes. Ou seja, seja qual for o código exemplo do livro, eles primeiro criam os testes, e depois codificam! Muito bom em minha opinião… O Refactoring aqui também come solto!
Agora, vou passar pra vc os livros que estão na minha lista de não lidos, que que vou ler em breve, se Deus quiser!!!
Addison Wesley - Test-Driven Development By Example
Pragmatic Unit Testing
Addison Wesley - Refactoring Improving the desing of existing code
Só complementando o shoes, use as 5 regrinhas (reflexão, simetria, transitividade, consistência e xyz != null, qdo xyz for não nulo) que toda implementação de um método equals deve obedecer como parâmetros para teste.