A palestra foi bem introdutória. Discuti sobre testes automatizados e TDD. Minha ideia maior foi motivar os participantes a escreverem testes automatizados, a conhecerem TDD, e a perceberem que dá pra fazer isso de maneira divertida!

Seguem meus slides!

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 busca por um design perfeito, que esteja preparado para aceitar mudanças e evoluir de forma simples, é difícil. Por esse motivo, a prática de TDD tem sido muito comentada pois, segundo seus praticantes, ela ajuda o programador a criar um design melhor.

Mas, a mais famosa frase da área de engenharia de software já nos diz que não existe bala de prata. Nenhuma prática garante o sucesso de um projeto ou um código de qualidade. As práticas estão lá para tentar manter o programador nessa direção.

E é a mesma coisa com TDD: a prática não resolverá todos os problemas de design que um programador enfrentará. O programador, na verdade, utiliza os testes para guiar o design. É através dele que o programador sabe se está indo no caminho certo ou não. Isso não quer dizer que TDD faz o design sozinho para o programador. É óbvio que o programador precisa ter experiência e conhecimento necessários para que o design saia realmente com qualidade.

Mas um programador que tenha alto conhecimento e experiência em desenvolvimento também pode criar um design com a mesma qualidade. A diferença é que TDD (e os testes gerados) dão feedback muito mais rápido sobre a qualidade. O gráfico abaixo, feito pelo Gleen Vanderburg, mostra o tempo de feedback de várias práticas ágeis. Veja que TDD dá feedback em minutos, ou seja, em alguns minutos o programador tem informações sobre o seu design. Através dos testes ele pode obter informações como a coesão da classe, o acoplamento, a simplicidade, etc. Novamente, o programador usa sua experiência para receber e entender esse feedback.

Figura 1. Práticas e tempo de feedback

Essa é na verdade a grande diferença para o design feito pelo arquiteto-astronauta, famoso no modelo Waterfall, para os designs ágeis. O arquiteto pode ter muita experiência, mas o design que ele faz leva tanto tempo para ser validado e receber feedback que, quando isso acontece, o custo de mudança é altíssimo.

Além disso, o programador ao usar TDD (e por consequência guiar seu design através dos testes) é “forçado” a utilizar bons princípios de orientação a objetos. Os tão falados princípios SOLID passam a fazer mais sentido no momento em que o programador precisa escrever um código que seja fácil de testar. Parafraseando Feathers, existe uma grande sinergia entre código fácil de testar e código bom. Esses bons padrões facilitam o programador a escrever um código mais fácil de testar, apesar do Mark Seemann discordar.

Novamente, a experiência do programador conta. O programador experiente sabe que deve gerenciar as dependências entre classes (DIP), sabe que as classes devem ser coesas (SRP), sabe que elas devem evoluir sem a necessidade de reescrevê-la (OCP), e etc. Programadores que não usam TDD também podem fazer uso desses bons princípios. A diferença é que TDD dá feedback quase instantâneo: a necessidade da utilização dessas ideias aparece após alguns minutos programando, o que não é verdade quando o programador não faz TDD.

Enfim, TDD não faz milagre. Mas ele fica lembrando o programador constantemente sobre a necessidade de manter o código limpo. E a necessidade disso é evidente. Com certeza outros programadores irão encontrar outras práticas que também dão feedback sobre qualidade de design ao desenvolvedor. Mas, enquanto isso não acontece, eu recomendo a utilização de TDD.

Mas lembre-se: é design guiado pelos testes (Test-Driven Design) e não design feito pelos testes!

Às vezes vejo pessoas interpretando errado o “escrever o código mais simples que faça o teste passar”. Na opinião delas, um if a mais é o código mais simples que ela pode escrever. E de repente, você tem um código cheio de if, praticamente ilegível, e só a partir daí é que começam as refatorações.

A ideia de escrever o código mais simples é justamente fazer com que o programador evite criar complexidade desnecessária. E na minha opinião, evitar na verdade complexidade de design (sabe aquela história de você criar uma façade que chama uma factory que cria um strategy que invoca um command, e por aí vai? Ou criar uma classe acoplada com outras 10 porque você acha que ela vai precisar?).
Se você for implementar uma soma (péssimo exemplo?), e escrever:

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

public class Calculadora {
  public int soma(int a, int b) {
    return 2;
  }
}

E logo em seguida…

public class CalculadoraTest {
  ...

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

public class Calculadora {
  public int soma(int a, int b) {
    if(a==3) return 5;
    return 2;
  }
}

E depois…

public class CalculadoraTest {
  ...

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

public class Calculadora {
  public int soma(int a, int b) {
    if(a==3) return 5;
    if(a==4) return 6;
    return 2;
  }
}

para só então chegar no código:

public class Calculadora {
  public int soma(int a, int b) {
    return a + b;
  }
}

… você não entendeu muito bem o objetivo de escrever o código mais simples que faça o teste passar!

No livro do Kent Beck [1], ele mostra o exemplo da classe Money, e ele faz os passos mais simples que fazem o teste passar. Passos realmente simplórios, parecidos com os do exemplo acima, que qualquer programador poderia considerar desnecessários. Mas logo em seguida, ele faz a seguinte afirmação: “Se eu faço assim o tempo todo? Claro que não. Mas eu fico feliz em saber que poderia fazer!”.

Ou seja, TDD não é fazer baby steps o tempo todo, e sim poder fazer baby steps quando necessário! Se você está escrevendo algum trecho de código complicado, você pode andar mais devagar; agora, se está escrevendo algum trecho de código simples, e você está confiante sobre isso, você pode dar um passo maior!

Um exemplo que me agrada muito em um outro artigo do Beck [2] é o exemplo de uma classe que lida com tabelas de mortalidade, ou seja, ela deve calcular valores de acordo com a idade de uma pessoa. Uma classe que poderia ser escrita naturalmente da seguinte maneira:

public class MortalityTable {
  public MortalityTable(Person person) {
    // ...
  }

  public Table calculate() {
    // usa Person aqui para calcular a tabela
  }
}

E ele mostra que, ao usar TDD para gerar essa classe, ele percebeu que (i) gerar uma entidade Person era complicado e (ii) a classe MortalityTable só precisava realmente da idade da pessoa para fazer o cálculo. Então, ele refatorou:

public class MortalityTable {
  public MortalityTable(int age) {
    // ...
  }

  public Table calculate() {
    // usa apenas a idade para calcular a tabela
  }
}

Ou seja, passar a idade para a classe MortalityTable era o jeito mais simples que ele tinha para resolver o problema! Isso sim é escrever o código mais simples que faz o teste passar! Perceberam a diferença?

Para terminar o post, gostaria de parafrasear o Jason Gorman: If “doing the simplest thing” tends to lead to lots of IF’s or Switch statements, it’s possible you’ve misunderstood TDD.

Referências

[1] Beck, K. Test-Driven Development: By Example. Addison-Wesley Professional, 2002.
[2] Beck, K. Aim, Fire. IEEE Software Volume 18 Issue 5, September 2001.

Se você está escrevendo testes para uma classe, e sente a necessidade de testar um determinado método privado de maneira isolada, isso é bom: você está recebendo feedback do seu teste em relação ao seu design! Afinal, não é isso que todos dizem sobre TDD?

E o que o teste está dizendo? Ele está te dizendo que sua classe não está coesa. Quando uma classe não é coesa, ou seja, ela tem mais do que uma responsabilidade (ela faz coisas demais!), geralmente existem um conjunto de métodos nela que são responsáveis por uma das responsabilidades, e um outro conjunto de métodos responsáveis pela outra responsabilidade.

Uma situação real: O programador criou uma classe para lidar com uma funcionalidade específica, e para isso criou um método público. A outra necessidade surgiu com o passar do tempo (às vezes nem tanto tempo assim; de repente ela apareceu 3 ou 4 testes depois!), e por ser algo que a funcionalidade inicial precisa, acabou virando um método privado dentro dessa classe. Esse método privado começa a crescer tanto que você quer testá-lo.

O que fazer? Extraia esse comportamento para uma nova classe. Essa nova classe será responsável somente por isso. Em seguida, faça a primeira classe depender dessa nova classe. Você conseguirá dar um nome bem significativo para essa nova classe, pois ela muito provavelmente representa um conceito de domínio, que até então estava escondido.

Extrair comportamentos para novas classes é algo muito comum ao se fazer TDD. Conforme o programador vai evoluindo a funcionalidade, novas responsabilidades aparecem e é muito tentador colocar todas elas no mesmo lugar. Que sorte a nossa termos o teste pra nos avisar!

Referências:

Martin, Robert. Principles of OOD. http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Feathers, Michael. The Deep Synergy between Testability and Good Design. http://michaelfeathers.typepad.com/michael_feathers_blog/2007/09/the-deep-synerg.html

Caroli, Paulo. Testing Private Methods, TDD and Test-Driven Refactoring. http://agiletips.blogspot.com/2008/11/testing-private-methods-tdd-and-test.html, 2008.

Suponha o seguinte código:

public class Copiadora {
  public void copiar() {
    var leitor = new LeitorDeXML();
    var escritor = new EscritorPelaSerial();
    while (leitor.TemCaracteres()) {
      escritor.Escreve(leitor.LeCaracteres());
    }
  }
}

Veja que essa classe é fortemente acoplada com duas classes: LeitorDeXML e EscritorPelaSerial. Se quantificarmos isso, podemos dizer que o acoplamento dessa classe é igual a “2″ (já que ela está acoplada a 2 classes).

Mas, ao fazer TDD, você naturalmente criaria um código parecido com isso:

public interface ILeitor {
  bool TemCaracteres();
  string LeCaracteres();
}
public interface IEscritor {
  void Escreve(string conteudo);
}
public class Copiadora {
  private ILeitor leitor;
  private IEscritor escritor;
  public Copiadora(ILeitor leitor, IEscritor escritor) {
    this.leitor = leitor;
    this.escritor = escritor;
  }
  public void Copiar() {
    while (leitor.TemCaracteres()) {
      escritor.Escreve(leitor.LeCaracteres());
    }
  }
}

Veja que agora a classe é acoplada com as interfaces ILeitor e IEscritor. Ainda assim, a métrica de acoplamento nos informaria “2″.

Qual a diferença? A diferença agora é que a classe está acoplada com módulos (classes, interfaces) mais estáveis. A estabilidade, segundo Bob Martin [1], mede o quão difícil (ou improvável) é realizar uma mudança na classe.

As classes LeitorDeXML e EscritorPelaSerial muito provavelmente são acopladas com outras classes (a classe EscritorPelaSerial, por exemplo, deve ser acoplada com alguma outra classe que auxilia na troca de mensagens pela porta serial) e isso faz com que elas possam eventualmente sofrer alterações; são classes mais voláteis. Já as interfaces ILeitor e IEscritor não dependem de nada, são independentes. Além disso, essas interfaces serão implementadas por várias outras classes, e isso faz com que essas interfaces sejam ainda mais difíceis de mudar (afinal, se você mudar uma delas, você vai ter que mudar a implementação em N classes que as implementam), tornando-as assim altamente estáveis.

Podemos dizer então que uma boa dependência é uma dependência com um módulo (ou classe) estável, e uma má dependência é uma dependência com um módulo (ou classe) instável. TDD faz com que o programador acople suas classes com módulos geralmente mais estáveis! Por quê? Porque TDD obriga você a pensar apenas no que você espera das outras classes, sem pensar ainda em uma implementação concreta. Esses comportamentos esperados acabam geralmente se transformando em interfaces, que frequentemente se tornam estáveis.

Para garantir um design de qualidade não basta apenas reduzir o acoplamento, mas sim acoplar com boas dependências! E para medir qualidade de design, também não bastam apenas métricas de acoplamento!

Referências

Esse post é fortemente baseado no trabalho do Bob Martin sobre princípios e métricas de qualidade em design de sistemas orientados à objetos.

[1] Martin, Robert C. Stability (http://www.objectmentor.com/resources/articles/stability.pdf)
[2] Martin, Robert C. Agile Principles, Patterns and Practices in C#

Obrigado a quem compareceu na apresentação! Os slides estão aqui!

Desvios comuns em TDD

View more presentations from mauricioaniche.

Qualquer dúvida, sugestão, crítica, por favor me mandem!

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