Dúvida com um exercício de TDD

Sao muitas perguntas em um post tao curto, mas vou tentar te ajudar.

Voce pode iniciar TDD de duas formas diferentes: outside-in e inside-out.

Eu prefiro fazer inside-out, ou seja, implemento com testes a parte principal da funcionalidade e vou indo para fora aos poucos, assim preciso mockar pouca coisa. Eu construo meus objetos de negocio em memoria, preferencialmente sem ter que espalhar a criacao deles por diversos testes, normalmente uso um builder que reutilizo onde preciso. Assim eu implemento primeiro a regra, com testes, e nos componentes mais externos uso objetos reais, ja implementados e testados, só tendo que mockar um mínimo de coisas, como componente de mensagens, entity managers e coisas do genero.

Ha quem prefira construir outside-in: Começa pelas partes externas e vai indo em direçao a regra. Confesso que tenho menos experiência com essa técnica, mas nos exemplos que já vi é criada mais uma camada de abstração entre o seu “controller” e seus objetos de negócio. Então você mocka essa abstracao nos testes e faz com que essa “fachada” retorne o resultado esperado.

Não entendi bem essa pergunta. Você diz, criar um método na classe só pra ser usado no teste?

Obrigado por responder,

YvGa:

Não entendi bem essa pergunta. Você diz, criar um método na classe só pra ser usado no teste?

O que quis dizer aqui foi usar um método do objeto testado em outro teste. Por exemplo, suponha que eu tenha uma classe que armazena uma data internamente, mas sua interface pública trabalha com string usando os métodos parse() e format(). Vou escrever um teste para o método parse()

MyDate dt = formatter.parse("01/01/2013");  // Esse é o método que estou testando
    assertEquals("01/01/2013", dt.format());       // Para validar fiz uso de um outro método, que também faz parte da classe testada (e provavelmente está coberta em outro teste)

É disso que estou falando. Eventualmente eu poderia até cair aqui em uma espécie de loop infinito - por exemplo, não consigo testar o parse() sem validar a condição com o format(), e não consigo validar o format() sem inputar dados antes com o parse().
Como fazer isso, devo permitir acesso ao campo em que a data é armazenada internamente, apenas para que os métodos de teste possam enxergá-lo?

Não sei se consegui explicar bem o caso da minha aplicação, mas o dilema é parecido com esse exemplo das datas: também tenho um método de entrada de informação e um de saída, ambos com lógica que precisa ser testada. Internamente o valor está em um campo que a princípio não seria de interesse de outras classes acessá-lo diretamente.

gomesrod:

Obrigado por responder,

Uma das possibilidades seria mockar uma interface que seu objeto implementaria, entao no “format” dele voce devolve o que quer, sem precisar "configurar’ seu teste novamente para testar outra coisa. Ou voce pode simplesmente configurar e testar outra coisa com uma mesma configuracao.

O que voce tem que ver é se existe realmente sentido nesse teste, se o que voce esta fazendo é realmente necessario testar. O caso do format, por exemplo, é um em que você não precisaria testar, você não precisa testar um metodo de outra api.

Talvez o exemplo não tenha ficado claro pra mim, mas a impressão que me passa é que você está testando algo que não precisaria ser testado, ou sua classe tem mais responsabilidades que deveria, pois um teste é um teste, se outro teste tem que testar a mesma coisa, antes de poder testar outra coisa, parece haver problema de acoplamento aí.

Nesse caso o format seria implementado pela minha classe.

É justamente esse tipo de coisa que estou tentando identificar.

Mas realmente não expliquei bem os exemplos, ficou tudo bastante confuso e vou recomeçar do zero.

Esqueça essa classe de datas, só serviu para complicar as coisas; vamos trabalhar com um exemplo parecido com o que estou realmente tentando desenvolver.

A classe em questão contém as “regras de negócio” de uma calculadora. Vou chamá-la de CalculatorEngine.

Suas funcionalidades são:

• Receber os valores inputados na GUI.

• Esses valores podem estar em Decimal, Binário ou Hexa. O usuário escolherá a base em que vai fazer o input.

• Armazenar o valor internamente em formato de número - Esse valor nunca será acessado diretamente pela GUI, portanto imagino que é um atributo privado.

• Fornecer o valor em Decimal, Binário ou Hexa - Assim é que a GUI terá acesso ao valor para exibir ao usuário.

• Além das funcionalidades de cálculo… mas isso vai ficar para a próxima etapa, por enquanto eu quero que funcione apenas como um conversor de base.

A API é mais ou menos assim (eu sei que no TDD é pecado ter código antes do teste, mas foi o único jeito de mostrar de maneira mais precisa o que estou imaginando)

class CalculatorEngine {
       private long currentValue; // O valor será armazenado aqui

       // A GUI chamará esse método para informar a base escolhida pelo usuário (binário, decimal ou hexa)
       void setInputBase(InputBase base) { ... }  

       // Quando o usuário pressionar alguma tecla a GUI chama esse método.
       // O valor será interpretado de acordo com a base escolhida.
       void input(String val) { ... }

       // Devolve os valores convertidos para serem exibidos pela GUI.
       String getValueAsDecimal() { ... }
       String getValueAsBinary() { ... }
       String getValueAsHexadecimal() { ... }
}

E o dilema é: como testar o método input() sem usar os getValue() para verificar o valor inputado ? E como testar os métodos de conversão (getValue) sem inserir valores com input() ?
Isso é o que quis dizer, o teste de um método depende de outro método e por isso pode ficar comprometido.

Isso se resolveria tornando visível o número real (atributo currentValue), mas para isso queria ter certeza que é aceitável quebrar o encapsulamento por causa dos testes unitários.

Ou ainda não entendi o seu exemplo ou não existe problema nenhum.

É normal você usar um método e depois testar o estado através de outro, ou testar o estado do seu objeto usando outros como input. Talvez ainda não tenha conseguido entender a sua duvida, mas a principio não me parece haver problema algum.

Se eu entendi direito, também tenho geralmente a mesma dúvida que você.
Aliás, quanto mais leio sobre OO, príncipios como “tell, don’t ask”, mais vejo dificuldade em testar esse tipo de coisa.

Pela sua explicação, seu atribute currentValue não precisa ser visível fora do objeto.
Então para ter acesso a ele, você sempre terá que usar método que retorne seu valor após ser aplicada alguma lógica.

Essa lógica pode inclusive aplicar alguma transformação, então na prática você estaria testando dois pedaços de lógica da mesma vez.

Algumas soluções que vejo por aí pra isso:

• Relaxar o encapsulamento para permitir o teste: deixar um método protected, por exemplo.

• Usar mocks para monitorar as interações do seu objeto.

• Testar as duas lógicas ao mesmo tempo.

Sinceramente não gosto muito de nenhuma delas, mas na prática acabo me adaptando a situação.

No seu exemplo específico, acho que pode estar atribuindo muitas responsabilidades para sua Engine e com classes menores ficasse mais simples.

Por exemplo: A base dos números, poderia ser apenas um conversor de entrada e saída, sendo transparente para sua classe.
Com isso você poderia expor diretamente o currentValue para o conversor ou injetar o conversor na Engine (passando um mock para testar o currentValue).

O que acha?

É aí mesmo que eu queria chegar… as soluções que me vieram à cabeça foram a primeira e a terceira. Segundo seu comentário não são o ideal, mas também não são nenhum crime e podem ser aplicadas dependendo do caso, certo?

YvGa:

Ou ainda não entendi o seu exemplo ou não existe problema nenhum.

É normal você usar um método e depois testar o estado através de outro, ou testar o estado do seu objeto usando outros como input. Talvez ainda não tenha conseguido entender a sua duvida, mas a principio não me parece haver problema algum.

Acho que aqui o quebra-cabeça se encaixa. Aquela sensação de que havia algo errado, excesso de responsabilidade, mas sem conseguir explicar exatamente por que… Era isso!
Os conversores deveriam ser objetos à parte! Parece que matou o problema, vou dar uma olhada mas creio que esse seja o caminho a ser seguido.

Quando eu disse sobre as responsabilidades eu estava falando sobre o seu metodo getValueAsDecimal(), por exemplo, delegar a sua implementação “as decimal” para uma classe especialista nisso e simplesmente utilizá-la. Veja que isso diminui a necessidade dos testes na classe que apenas usaria esse “AsDecimalzador”, ou seja na classe que possui o metodo getValueAsDecimal() você não precisa testar a conversão propriamente dita, já que ela é delegada, precisando testar apenas exceções ou fluxos diferentes que essa conversão venha a obrigar. Para isso, caso seja simples você pode configurar “AsDecimalzador” para testar seu getValueAsDecimal(), mas sem se preocupar em testá-lo nesse momento, ou pode mockar e retornar o esperado para suas exceções e fluxos diferentes.

Não sei se me fiz entender ou compliquei mais ainda.

Eu não vejo problema de usar o método input e o método getValueAsDecimal num mesmo teste.

Se o valor de currentValue é um detalhe de implementação, você não deve checá-lo com os testes unitários. Se você fizer isto, ao alterar a representação interna do objeto (a implementação), seus testes quebram. Se você considerar que no TDD os testes são uma especificação, não é interessante que eles sejam dependentes de detalhes de implementação. O método input altera o estado do seu objeto. Você precisa checar se o estado foi alterado adequadamente. Para isto, use um método disponível na sua interface pública. getValueAsDecimal (ou outro semelhante) podem resolver o teu problema.

A unidade (do unit test) nem sempre representa um único método: testar o método input em isolado não dá, bem como testar o getValueAsDecimal em isolado também não.

Usar um conversor separado pode ser interessante, pois te permite testar as operações de conversão separadamente. Mas o método input continua lá e você não testou se ele de fato alterou o comportamento do objeto.

Pensando em OO, currentValue é uma propriedade do objeto, assim como getValueAsDecimal. Por que você não veria problemas em checar o valor do primeiro, mas acha ruim checar o segundo?

YvGa:

Quando eu disse sobre as responsabilidades eu estava falando sobre o seu metodo getValueAsDecimal(), por exemplo, delegar a sua implementação “as decimal” para uma classe especialista nisso e simplesmente utilizá-la. Veja que isso diminui a necessidade dos testes na classe que apenas usaria esse “AsDecimalzador”, ou seja na classe que possui o metodo getValueAsDecimal()

Verdade, mas acho que não dá para fugir disso… agora que os conversores estão em um objeto à parte preciso de uma maneira de obter o valor “puro” que está no objeto; provavelmente vai ser necessário também incluir esse acesso na interface pública da classe.

wagnerfrancisco:

Pensando em OO, currentValue é uma propriedade do objeto, assim como getValueAsDecimal. Por que você não veria problemas em checar o valor do primeiro, mas acha ruim checar o segundo?