[tweet]Software bom, que atende ao negócio com custo apropriado, demanda boas práticas de engenharia de software.[/tweet] Dentre essas práticas, destaca-se, sem dúvidas, o desenvolvimento de testes automatizados. Entretanto, não podemos ignorar o fato de que estes custam tempo e dinheiro, afinal, são códigos que precisam ser produzidos e mantidos. Quando são mal feitos, não compensam o investimento.

Testes difíceis de entender, por exemplo, aumentam o tempo que o programador precisa para fazer ajustes em uma base de código. Além disso, quando acusam falha, não ajudam a detectar rapidamente como resolver o que há de errado. Ou seja, mesmo que tenham valor por evitar erros em produção, poderiam agregar ainda mais.

Em bases de código C# não é raro encontrar testes verificando o funcionamento dos getters e setters. Entretanto, convenhamos que esse funcionamento é garantido pela Microsoft e, seguramente, já foi testado por seus programadores.

public class Customer
{
  public string Name { get; set; }
  // ..
}

/* ------------------------------------- */
public class CustomerTests
{
  public void GetterAndSetterWorkForNameProperty
  {
    var c = new Customer();
    c.Name = "John Doe";
    Assert.Equal("John Doe", c.Name);
  }
}

Há também aqueles testes que, embora adicionem algum valor, quebram facilmente durante a evolução do sistema. Em suma, são testes frágeis com alto custo de manutenção. Por exemplo, testes de construtores que inicializam propriedades de uma classe.

public class CreateUserCommand
{
   public CreateUserCommand(string name)
   {
      Name = name ?? throw new ArgumentNullException(nameof(name));
   }
   
   public string Name { get; }
}

/*-------------------------*/
public class CreateUserCommandTests
{
    [Fact]
    public void UserNameIsMandatory()
    {
       Assert.Throws(() => new CreateUserCommand(null));
    }
}

[tweet]Testes ruins valem menos que o espaço que consomem nos dispositivos de armazenamento.[/tweet] Mais que isso, são também dívidas técnicas pois geram impacto negativo para o negócio e para os times técnicos.

De forma objetiva, [tweet]o custo para desenvolver e manter software com testes deve ser menor do que seria se não houvesse teste algum.[/tweet] Quando não é assim, há algo muito errado.

Bons testes protegem contra regressão, dão segurança para atividades de refatoração, contribuem para a redução do lead time e reduzem os custos de manutenção. [tweet]Com o tempo, boas bases de testes também ajudam a previnir erros, mas este é apenas um efeito colateral positivo.[/tweet]

Testes podem ser usados apenas para demonstrar a presença de bugs, nunca a ausência! – Edsger W. Dijkstra