Esse problema acontece pois grande parte das APIs que lidam com datas, tanto no mundo .Net quanto no mundo Java, fazem uso de métodos estáticos. Por exemplo:

DateTime.Now // C#
Calendar.getInstance() // Java

Generalizando o problema, a dificuldade nao é testar datas, mas sim qualquer classe que faz uso de métodos estáticos. Por exemplo, como escrever um teste para o método abaixo?

public int DiasEntreHjEAData(DateTime data) {
  return (DateTime.Now - data).TotalDays;
}

A propriedade Now sempre irá devolver a data corrente, dificultando assim a escrita do teste; como escrever um teste onde o cenário muda o tempo todo?

Não conseguir simular o comportamento do método Now, e esse eh um dos problemas de usar métodos estáticos: dificulta o teste das classes que os utilizam (além de não permitir o uso decente de polimorfismo, mas isso é uma outra discussão…)

Para resolver esse problema, precisamos deixar de usar métodos estáticos. Mas e como fazer com as APIs que já existem, e não podemos mudá-las, como é o caso da API de DateTime?

Isso não nos impede de criarmos uma abstração em cima disso! Veja o código abaixo:

public interface Relogio {
  DateTime Hoje();
}

public class RelogioDoSistema : Relogio {
  public DateTime Hoje() {
    return DateTime.Now;
  }
}

Veja que criamos a interface Relogio, que abstrai o problema de calcular a hora atual. Nosso método acima agora, em vez de invocar o método estático, faz uso da nova abstração:

public class Algoritmo {

  // recebido pelo construtor
  private Relogio relogio;

  public int DiasEntreHjEAData(DateTime data) {
    return (relogio.Hoje() - data).TotalDays;
  }
}

Pronto. Veja agora que testar essa classe é facil. Basta passarmos um mock e simular o comportamento esperado do Relogio.

Resumindo, métodos estáticos dificultam a escrita de testes de unidade. Para resolver isso podemos: evitar a escrita de métodos estáticos, ou criar abstrações que escondem esses métodos. Nao é feio criar abstrações como a Relogio; feio é não testar!

Muitas pessoas discutem a necessidade de ter 100% de cobertura em um código. Mas não vejo problemas em códigos que não tenham 100% de cobertura de testes de unidade.

Acredito que isso deve ser uma meta da equipe, buscar sempre a maior cobertura possível; mas essa é uma meta que você provavelmente não vai alcançar; alguns trechos de código simplesmente não valem a pena serem testados de maneira isolada!

Explico: Veja essa classe do Restfulie.NET, por exemplo, chamada AspNetMvcUrlGenerator: ela serve para gerar URLs para Actions em Controllers, utilizando as rotas pré-definidas. Repare que ela faz uso intenso das APIs do Asp.Net MVC, utilizando inclusive alguns métodos estáticos (que sabemos que é difícil de testar) como no HttpContext.

public class AspNetMvcUrlGenerator : IUrlGenerator
    {
        public string For(string controller, string action, IDictionary values)
        {
            var httpContextWrapper = new HttpContextWrapper(HttpContext.Current);
            var urlHelper = new UrlHelper(new RequestContext(httpContextWrapper,
              RouteTable.Routes.GetRouteData(httpContextWrapper)));

            return FullApplicationPath(httpContextWrapper.Request) +
              urlHelper.Action(action, controller, new RouteValueDictionary(values));
        }

        private string FullApplicationPath(HttpRequestBase request)
        {
            var url = request.Url.AbsoluteUri.Replace(request.Url.AbsolutePath,
               string.Empty) + request.ApplicationPath;
            return url.EndsWith("/") ? url.Substring(0, url.Length - 1) : url;
        }
    }

Eu até poderia ter feito alguma mágica e escrito um teste de unidade para esse código. Mas para quê? Apenas para aumentar o número? Não faz sentido! Esse trecho de código precisa de um teste de integração, e não de um teste de unidade!

Um outro exemplo é o teste de propriedades (Properties do C#). Preciso realmente deles? A própria linguagem implementou isso pra mim. O mesmo acontece no caso dos getters/setters do Java, onde o programador geralmente usa o Eclipse para gerá-los.

Você precisa cobrir seu código de testes, mas você pode usar testes de diferentes níveis para isso (testes de unidade, de integração, de sistema, etc)! Escrever testes de unidade inúteis, apenas para chegar nos 100% de cobertura, é desperdício.

Há um mês atrás comecei a escrever um post sobre isso, mas meu exemplo era muito fraco. Corri então para olhar testes de alguns dos últimos projetos que participei, e pasmém: na maioria deles só havia uma asserção!

Ao observar os testes que continham mais de uma asserção, percebi que eles aconteciam nos seguintes casos:

1. Quando o método retorna uma lista, array ou uma classe responsável por armazenar uma coleção de determinado objeto;
2. Quando o método retorna um novo objeto;
3. Quando o método é parte de uma DSL;

Nos testes do tipo (1), as asserções mais comuns são para verificar o tamanho da lista e se o elemento existente nela é o esperado. Além disso, se o teste espera mais de um elemento na lista, o teste faz algum tipo de loop para verificar; Nos testes do tipo (2), o método de teste realiza asserções sobre os atributos do objeto retornado; E, finalmente, nos testes do tipo (3), que geralmente testam a DSL, e nesse caso um teste realmente testa mais de um comportamento ao mesmo tempo, e por isso, verifica mais de um comportamento.

Resolvi portanto perguntar a opinião de outros desenvolvedores sobre a regra. Para isso, enviei a pergunta no twitter (de forma não enviesada, perguntando apenas a opinião e, para os que me responderam de volta, exemplos de código aonde isso fizesse sentido).

Algumas pessoas concordaram com a ideia de apenas uma asserção por teste, afirmando que a regra ajuda a manter o código mais simples e mais fácil de manter. Além disso, quando o teste quebra, é fácil perceber o problema.

Outros já discordaram da regra, e afirmaram que o programador deve tentar escrever sempre o menor número possível de asserções, mas que a regra não precisa ser seguida à risca. Discutindo um pouco melhor esse ponto de vista, muitos deles afirmaram que um teste deve testar apenas uma única funcionalidade, não importando o número de asserções necessárias para tal.

Infelizmente a quantidade de códigos enviada foi muito baixa. Mas, o interessante é que um dos códigos enviados se encaixa em (1). Já o outro código enviado, retirado de um livro de Ruby, não se encaixa em nenhum dos exemplos acima, mas pode-se dizer que aquele teste está na verdade testando duas funcionalidades: string com espaços no começo e no fim e string sem espaços.

A ideia desse post é portanto, fomentar essa discussão. Alguém tem um outro exemplo aonde mais de uma asserção por teste faça sentido, mas que não se encaixa nos casos acima?

Agradecimentos

Obrigado ao @elemarjr, @viniciusquaiato, @FabioVazquez, @pedroreys, @pisketti, @danielsilvarj, @carlosgaldino, @rodbv, @cessor, @alexandregazola, que responderam no Twitter.

A primeira e mais óbvia resposta é: quando o teste deixar de fazer sentido! Se a funcionalidade foi removida, você deve atualizar sua bateria de testes e apagar todos os testes relacionados à ela. Bateria de testes desatualizada não serve pra nada! Se a funcionalidade evoluir, você deve evoluir seus testes juntos.

Até aí nada de novidade… Mas vamos lá.

A segunda resposta é: quando você tem testes repetidos! Em algumas situações, quando estamos em dúvida sobre como implementar determinada funcionalidade, optamos por escrever testes parecidos para, de alguma forma, triangularizar até chegar na implementação correta.

Voltando ao velho exemplo da calculadora. Suponha que implementar um algoritmo de soma fosse algo complicado. Você começou com testes simples, como (1+1), depois (1+2), depois (2+2). Nesse momento você encontrou uma maneira de resolver o problema para quaquer (m+n). Seus testes de unidade ficam parecidos com esses:

public class CalculadoraTest {
  @Test
  public void deveSomarUmMaisUm() {
    assertEquals(2, new Calculadora().soma(1,1));
  }

  @Test
  public void deveSomarUmMaisDois() {
    assertEquals(3, new Calculadora().soma(1,2));
  }

  @Test
  public void deveSomarDoisMaisDois() {
    assertEquals(4, new Calculadora().soma(2,2));
  }
}

Esses testes, muito úteis durante o tempo de desenvolvimento do algoritmo, agora se tornaram repetidos. Você, portanto, deve apagá-los! Eles, além de serem inúteis, ainda dificultam o trabalho do desenvolvedor. Se um dia o método testado mudar, você terá que mudar em 10, 20 testes diferentes (mas que testam a mesma coisa!). Lembre-se do acoplamento entre seu código de teste e seu código de produção (sim, ele existe!).

Mas poxa, um testezinho só não é pouco? Não! Você precisa de apenas um teste para garantir a funcionalidade. Não adianta testar a mesma coisa duas vezes.

Você deve ter apenas um teste para cada conjunto de estados válidos e inválidos para uma condição de entrada. A ideia é que todos os elementos de uma classe se comportem de maneira similar. A esses conjuntos damos o nome de classes de equivalência. Escrever apenas um teste por classe de equivalência é uma prática muito comum em testes de caixa preta e é conhecida como particionamento em classes de equivalência. Apesar disso, acredito que ela faça sentido também para testes de caixa branca, como os testes de unidade.

No nosso exemplo da calculadora, poderíamos ter testes para, por exemplo:

• soma de dois números positivos;
• soma de um número positivo com outro negativo;
• soma de um número negativo com outro positivo;
• soma de dois números negativos;
• soma com um dos elementos sendo zero;

public class CalculadoraTest {
  @Test
  public void deveSomarDoisNumerosPositivos() {
    assertEquals(4, new Calculadora().soma(2,2));
  }

  @Test
  public void deveSomarPositivoComNegativo() {
    assertEquals(4, new Calculadora().soma(6,-2));
  }

  @Test
  public void deveSomarNegativoComPositivo() {
    assertEquals(-4, new Calculadora().soma(-6,2));
  }

  @Test
  public void deveSomarDoisNumerosNegativos() {
    assertEquals(-4, new Calculadora().soma(-2,-2));
  }

  @Test
  public void deveSomarComZero() {
    assertEquals(4, new Calculadora().soma(0,4));
    assertEquals(4, new Calculadora().soma(4,0));
  }
}

Obviamente, encontrar todas as classes de equivalência não é um trabalho fácil, e por isso temos a gigante área de testes de software. Mas não é repetindo testes que você garante que seu código funciona.

Referências

Maldonado, Jino, Delamaro. Introdução ao teste de software. Editora Campus, 2007.

TDD é uma atividade de design. O teste de unidade que você escreve serve basicamente para definir suas expectativas em relação ao código que você vai escrever. E, ao fazer isso, você pensa não só no nível da implementação do algoritmo, mas em um nível um pouco mais alto: no nível de design. TDD permite que você brinque e experimente diferentes possíveis designs, dando feedback rápido sobre o resultado obtido, até que você encontre o design ideal para aquela situação.

Ou seja, quando você faz TDD, você pensa exclusivamente em design e não em testes. É uma prática de suporte para design de software.

Mas… É claro que você precisa testar! Você não apaga os testes que você produziu usando TDD, óbvio. Mas muito provavelmente eles não testam todas as possibilidades possíveis. E é aí que outras técnicas entram em cena, e você pode encontrar muita informação sobre elas em [1][2].

Resumindo, use TDD quando você precisa trabalhar no design de determinada classe ou módulo. Quando você estiver satisfeito com design, é hora de testar! Aí você pode fazer test-first, test-last, ou que você preferir, mas teste de verdade!

[1] The Art of Software Testing – Myers
[2] Introdução ao Teste de Software – Maldonado, Delamaro, Jino

Eu ia pular a questão inicial, mas vou revisar para que facilite o entendimento do resto do post para quem não leu os links acima. Uma entidade pode conhecer/utilizar um repositório? Acho que a resposta é óbvia: Sim. Repositórios são conceitos de negócios, fazem parte do domínio, e por isso não há nada de errado em uma entidade conhecer um repositório. Não vou entrar no mérito de como o repositório deve ser implementado, não é o meu interesse no momento. Mas vamos lá… Ok, podemos ter entidades que dependem de um repositório, e o problema é: como gerenciar essa dependência?

A seguir, discutimos algumas abordagens para resolver esse problema e chegamos em algumas conclusões, das quais gostaria de compartilhar.

Sugestão I: Receber o repositório pelo construtor
A entidade deve possuir um construtor que receba a dependência.

Vantagens:

• A dependência fica explícita, ou seja, não há como criar uma entidade sem entregar a dependência já resolvida.

Problemas:

• Torna o código menos legível, afinal sempre que for instanciar uma entidade, deve-se injetar seu repositório.
  Ex: Pessoa mauricio = new Pessoa ( repositorioDePessoas );
• Imagine uma entidade que depende de mais de um repositório (por quê não?). Imagine passar os diversos repositórios no construtor. Menos legível ainda…
  Ex: Pessoa mauricio = new Pessoa ( repositorioDePessoas, repositorioDeXPTO, repositorioDeXYZ );
• Isso fica pior ainda quando definimos um construtor que receba algum atributo, por exemplo.
• Ex: Pessoa mauricio = new Pessoa ( “mauricio”, “aniche”, repositorioDePessoas, repositorioDeXPTO );

Testabilidade:

• É fácil injetar um mock no lugar da dependência, para facilitar o teste unitário da entidade.

Sugestão II: Definir um setter para a dependência
A entidade deve ter um método setDependencia() que receba a dependência.

Vantagens:

• Elimina o problema de resolver a dependência no momento da criação do objeto.

Problemas:

• Você precisa setar a dependência sempre que for utilizar, e isso pode ser um problema. Você precisará fazer todo o tempo algum tipo de validação no código da entidade para saber se a dependência já foi injetada ou não.
  Ex: public List<XPTO> pegaXpto(int abc) { if(repositorio!=null) repositorio.pegaX(abc); }

Testabilidade:

• Também é fácil injetar um mock no lugar da dependência.

Sugestão III: Utilizar o próprio repositório para injetar repositórios nas entidades
Conforme sugerido pelo Paulo Silveira e pelo Fabio Kung no post, sempre que um objeto for recuperado pelo seu repositório, o mesmo deve se “auto-injetar” antes de devolver o objeto.

Vantagens:

• A complexidade do gerenciamento desse dependência fica escondida no código do repositório.
• O código a ser implementado, de maneira geral, é simples.

Problemas:

• Apesar de ser simples, deve ser replicado em todos os métodos do repositório. Se o método do repositório retornar uma lista, por exemplo, deve-se repetir o processo em todos os elementos dessa lista.
• Apenas as entidades que são recuperadas pelo repositório recebem a dependência. Entidades criadas em qualquer outro ponto do projeto não recebem essa dependência de forma automática. Isso pode causar o problema levantado na sugestão II.
• Caso a entidade mude e venha a depender de um outro repositório, você terá muito código para alterar.

Testabilidade:

• Da mesma maneira que o repositório injeta a dependência (através de um setter), pode-se injetar um mock.

Sugestão IV: Injetar o repositório por AOP
Uma idéia bastante interessante seria injetar a dependência por AOP. Dessa maneira não importaria como o bean é instanciado, seja ele feito pelo JPA, Hibernate, etc, ou pelo programador. Essa foi uma sugestão levantada pelo Alessandro Lazarotti, nesse post do GUJ.

Vantagens:

• O código fica bastante claro.

Problemas:

• A implementação de um aspecto geralmente não é trivial.

Testabilidade:

• Dependendo do modo que o aspecto for implementado, talvez não seja tão trivial injetar a dependência. Para facilitar, pode-se criar um setter exclusivamente para isso, mas não é muito elegante.

Sugestão V: Resolver a dependência dentro da própria entidade
A idéia seria a própria entidade resolver a sua dependência. No caso, ela mesma invocaria o framework de DI, e recuperaria a instância da dependência. Pode-se até pensar em uma Factory para que a entidade não dependesse diretamente de uma implementação de framework de DI.

Vantagens:

• Solução bastante simples.
• Acaba com o problema da necessidade da entidade validar se a dependência foi injetada ou não, já que ela mesma vai resolver.

Problemas:

• Não é muito elegante fazer com que a própria classe resolva suas dependências.

Testabilidade:

• Como é a própria classe que resolve a dependência, você precisará de um setter para conseguir injetar um mock. Como dito acima, não é muito legal.

(*) Além do que foi citado acima, existe um outro problema, ortogonal ao das dependências, e diz respeito diretamente à implementação desse projeto em particular. Por estarmos discutindo uma aplicação web, o contexto do Spring está guardado dentro do contexto web. Para que um POJO qualquer recupere esse contexto, ele precisaria conhecer o servletContext. Ainda não encontrei uma maneira muito clara para resolver isso, mas minha sugestão é criar uma classe singleton que conteria um atributo com uma instância de contexto do Spring, e essa instância seria injetada por um filter ou um listener qualquer, que subiria logo após ao listener do Spring. A partir daí, todas as classes de domínio fariam acesso à esse singleton para capturar o contexto.

Portanto, é possível gerenciar essa dependência de diversas formas, todas elas com suas vantagens e desvantagens. E você, como faz?