A Engenharia de Software tem uma disciplina chamada Verificação e Validação de Software. Sua intenção é responder as perguntas: Estamos contruindo o produto corretamente?(Verificação) e Estamos contruindo o produto correto?(Validação). Textos como: Growing Object-Oriented Software, Guided by Tests, ou o texto do Scott Ambler, que apresenta várias técnicas de teste, The Full Life Cycle Object-Oriented Testing (FLOOT) Method é reforçado que o objetivo dos testes é verificar se o software está se comportando conforme o esperado.

Influenciado por essa linha de pensamento, eu tenho, um certo, nojinho de testes que quebram quando o comportamento não foi alterado, mas a implementação mudou.

Sobre testes que testam implementação

Recentemente, passei pela seguinte situaçõa:

Modelo

Temos 3(três) classes: A, B e C.

Classe A é antecessora de B. Isto é, B herda de A suas propriedades. Classe B tem uma associação com muitos objetos da classe C.

Em Ruby, fica assim:

class A; end

class B < A
  has_many :c
end

class C; end

O Teste

describe B
  it { should have_many :c }
end

A mudança

A associação subiu na hierárquia, indo de B para A.

Antes

class A; end

class B < A
  has_many :c
end

Depois

class A
  has_many :c
end

class B < A; end

Na minha opinião, o teste não tem motivo para quebrar, uma vez que não há mudança no comportamento de B.

Evoluindo a análise, esse matcher, do RSpec, parece não ser feito para esse propósito.

Penso que a utilidade dele, é testar uma gem, por exemplo, que crie uma associação. E, por isso precise verificar se a associação está presente.

Me pergunto: Por que testar a implementação, ao invés do comportamento?

Qual a opinião de vocês sobre o assunto?