Foi uma verdadeira revelação para mim quando meu companheiro, colega programador e ex-mentor do rubi, Brian Guthrie @bguthrie me deu este conselho.
Eu tinha acabado de chegar a Melbourne, tinha acabado de começar a ‘levar meu ofício a sério’ e estava no Retiro de Código de Corey Haines em Melbourne 2011 – que Brian estava facilitando.
Como um aparte; se você ainda não participou de um, recomendo que experimente. É um ótimo ambiente para praticar a arte de organizar códigos com pessoas realmente inteligentes e sem pressões externas.
No instante em que ouvi, soube que era verdade. É algo tão óbvio que eu sabia que deveria ser capaz de articular – mas nunca coloquei em palavras, ou pensamento coerente.
Por quê?
A razão de existir do seu objeto (sua responsabilidade) é exposta pelas mensagens que ele pode aceitar. Supondo que seu código de tempo de execução apenas exercite seus métodos públicos, seus testes devem ser capazes de encontrar todas as arestas fazendo o mesmo.
Quando os detalhes da implementação estão ocultos, os testes são muito menos quebradiços / frágeis. Você é livre para refatorar a implementação privada o quanto quiser, sem ter que ir e mudar seu teste (afinal, por que deveria? O resultado é o que você está especificando no teste e permanece o mesmo).
Se sua API pública não exercita todas as arestas de sua implementação privada, você certamente tem código redundante.
O que torna esta orientação realmente atemporal é a cordialidade recíproca que possui com uma série de outras boas práticas. Os porquês acima sugerem que:
- O pensamento foi para a responsabilidade (singular!) Do objeto
- Alguns códigos são meramente detalhes de implementação e, portanto, desinteressantes para o mundo exterior
- O foco nos resultados torna os testes mais robustos
- As mensagens em um sistema OO são o que é realmente interessante
Adoraria ouvir as experiências de outras pessoas com essa diretriz. Certamente, se alguém tiver um exemplo de onde é necessário testar os métodos privados de seus objetos, eu adoraria ouvi-los.
kthxbi, Stu