Testes, primeira temporada, episódio um

February 4th, 2009 § 2 comments

No último artigo, falei um pouco sobre a preocupação arquitetural que deve permear os testes e fiquei devendo um exemplo.

Para não entrar em detalhes específicos do Rails e viciar a discussão, me lembrei de um exemplo que li há vários anos, quando estava começando a estudar XP, de um sessão entre dois programadores experientes fazendo pair-programming para chegar em um corpo de testes expressivo com base em um problema bem específico.

O exemplo é real e foi protagonizado por Robert C. Martin, um dos assinantes originais do Agile Manifesto e Robert S. Koss. Para ler o exemplo, siga para a página do mesmo.

Como é possível ver claramente pelo exemplo, a implementação secundária–representada pela classe Scorer–não possui um teste em particular. Entretanto, está fielmente testada através do seu relacionamento com o objeto mais importante. A preocupação arquitetural está no que as duas classes fazem em conjunto e não com o que cada uma delas possui como função. Note, inclusive, que classes secundárias são consideradas e descartadas sem que as mesmas sejam objeto de testes mais do que de passagem.

Obviamente, em uma arquitetura saudável, classes dominantes aparecerão e terão um foco maior em testes. O importante, então, é manter a visibilidade do domínio que está sendo testado.

No caso específico do Rails, o grande problema está em como aplicações são geralmente desenvolvidas. Por causa da separação convencionada do domínio MVC da aplicação, muitos desenvolvedores acreditam que essa é a única forma que se pode desenvolver aplicações usando o framework. O alvo, quando usando o Rails, não deve ser aplicar essa estrutura cegamente mas conseguir segregar papéis e funções de modo que o todo seja coerente.

Essa é uma visão bem geral do assunto e poderíamos nos estender em vários aspectos. Perguntas e comentários são bem-vindos.

Tagged

§ 2 Responses to Testes, primeira temporada, episódio um"

  • Eduardo Rocha says:

    Ronaldo, segundo o artigo do Fowler (http://martinfowler.com/articles/mocksArentStubs.html), você seria um “classicist”? No exemplo específico de testes de controller, você usa mocks, ou verifica se o valor no banco de dados foi alterado?

  • Ronaldo says:

    Opa, Eduardo! Tudo bom?

    Eu estou me tornando um classicista. Durante um bom tempo, eu fiz testes “by the book”, especialmente com o RSpec onde o mantra é mock/stub para tudo. Descobri que o resultado era testes quebradiços e repetitivos em muitos casos.

    Atualmente, eu estou pendendo mais para o lado de usar objetos reais mesmo que em alguns casos isso implique em mais trabalho inicial. No caso particular de controllers, eu tendo agora a usar chamadas reais no banco de dados sempre que for possível.

    No caso do middleware que citei no primeiro artigo, quase todos os testes são feitos contra as bibliotecas reais sob o mesmo. Eu não consigo nem dizer quantas horas isso salvou na implementação. Mocks teriam tornados os testes mais rápidos mas não a implementação mais segura. Obviamente, nesse caso as bibliotecas são embutidas o que torna tudo mais fácil. Usei o RR, um framework de test doubles para Ruby que tem a característica especial de ter mocks com proxies. Isso permite ter expectativas e ainda assim exercer a implementação real. Foi uma combinação muito boa.

    Tudo isso dito, nem de longe tenho uma solução completa. Há tanta coisa para revisar e repensar que qualquer conhecimento adicional é sempre bem-vindo.

Leave a Reply

Your email address will not be published. Required fields are marked *

What's this?

You are currently reading Testes, primeira temporada, episódio um at Superfície Reflexiva.

meta