Ao contrário do software procedimental, o software orientado a objetos nem sempre se comporta da mesma maneira se executarmos o mesmo método com os mesmo valores de entrada. Essa afirmação pode parecer chocante, mas é sensata, e justifica uma das dificuldades de testar software orientado a objetos.
Uma das maiores peculiaridades do software orientado a objetos é o controle de estados. O estado de um objeto caracteriza sua composição em um dado momento de tempo. Dentro da UML temos diversos diagramas (i.e., Diagrama Temporal, Diagrama de Estados) que tratam de representar a troca de estados dos objetos.
E por que é difícil testá-lo? Por que a afirmativa acima é sensata? Vamos discutir isso através de um exemplo…
Vamos supor uma classe que possua a seguinte implementação:

Se criássemos um teste unitário para o teste do método “MultipleRex(int)”, possivelmente ele seria implementado da seguinte forma:

Mas, se observarmos de forma mais detalhada o comportamento do método “MultipleRex(int)”, veremos que existe dependência à um atributo interno. Tal dependência é tão forte, que o valor deste atributo influência quais blocos de código que podem ou não serem executados. Um conjunto de condições aninhadas, que validam o atributo _sault, direciona a execução do método para um bloco de código distinto dos demais. Blocos de código que podem conter lógicas mais complexas, chamadas a outros métodos, construção de outros objetos, comunicação com satélites, enfim… códigos que estão propensos ao erro.

Desta forma, se incluirmos a chamada a um método intermediário entre a execução do nosso método sob teste e a instância do objeto, alteraremos o comportamento do nosso método, mesmo passando os mesmos valores de entrada. Podemos confirmar isso através do exemplo abaixo:

A execução do método “MultipleRex(int)” modifica o valor do atributo privado e altera os blocos de código executados pelo método “MultipleRex(int)”, acarretando em um valor de retorno diferente do esperado.

Se modificarmos nosso teste, e trocarmos o método intermediário, acarretaremos na execução de um terceiro comportamento distinto. A alteração pode ser vista no exemplo a seguir:

Assim, podemos afirmar que, o teste de software orientado a objetos, não apenas por este motivo, mas por um conjunto de peculiaridades próprias do paradigma orientado a objetos, é difícil de ser testado e exige que dediquemos atenção durante a construção dos nossos casos de teste. De forma que seja abrangente o suficiente, a fim de executar todos os possíveis blocos de execução de nossas aplicações.

Por
Fernando Henrique Inocêncio Borba Ferreira.