Olá!
No dia 7 de Fevereiro de 2013 tive a honra de participar de um evento no grupo .Net Coders.
O .Net Coders é uma comunidade muito bacana que existe aqui em São Paulo e que a (cerca de) um ano tem agitado a comunidade paulista com diferentes eventos, abordando assuntos gerais da área de tecnologia e mais especificamente, diferentes segmentações da plataforma .Net.
Olá,
Você conhece as diferenças entre os termos defeito, erro e falha? Parecem ser conceitos muito parecidos, comumente generalizados pela palavra “bug”. Mas estes três termos expressam idéias, situações e usos diferentes.
Defeitos são caracterizados como passos, processos ou definições de dados incorretas. Um defeito ocorre no nível mais baixo do hardware ou em uma linha de código. O defeito é a causa de um erro, mas não necessariamente sempre acarreta em um erro, pois a linha que contém um defeito pode nunca ser executada.
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.
Fernando Henrique Ferreira 