Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
código fonteDublês de Teste - Revista Java Magazine 104
Este artigo apresenta como podemos criar testes de unidade de uma forma que as dependências entre as classes não sejam um empecilho para a validação da implementação.
[fechar]
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
Java Magazine 104
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 104
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 104
Por Ismael Soares e Rogério Gomes Rios
Que os projetos de desenvolvimento de software falham ou têm algum tipo de falha, já sabemos. Mas o que poucas pessoas têm conhecimento é que erros, conhecidos como “bugs”, custam muito caro às empresas e a seus clientes. Uma pesquisa feita pela Gartner revela que este custo chega a cerca de 60 bilhões de dólares por ano nos Estados Unidos. A justificativa para tanto prejuízo está no fato de grande parte destas falhas serem resolvidas tardiamente, quando o software já está em produção. A pesquisa informa ainda, que o processo utilizado para o desenvolvimento dos softwares reflete na qualidade final do produto.
De uma forma geral, o processo de desenvolvimento de software pode ser enxergado como uma metodologia ou conjunto de práticas que auxiliam a produção de um software. Essas práticas culminam em um produto que reflete a forma como todo o processo foi conduzido.
Uma prática muito comum em equipes ágeis é utilizar o TDD, ou Desenvolvimento Orientado por Testes, que ganhou tremenda popularidade nos últimos anos. No entanto, o uso desta técnica fica limitado por diversos fatores, tais como: falta de conhecimento do time, arquitetura mal elaborada, código legado e, principalmente, dependências internas e externas (outras classes, serviços, banco de dados, etc.).
Com base nisso, neste artigo apresentaremos algumas formas de resolver facilmente o problema com as dependências utilizando Dublês de Teste, que simulam o comportamento de objetos reais de forma controlada.
Dublês de Testes
Quando a indústria do cinema quer filmar algo que exige um nível mais especializado de formação e/ou capacidade física para o ator principal, eles contratam um “dublê” para tomar o lugar na cena. O dublê é um indivíduo altamente treinado, capaz de atender aos requisitos específicos da cena. Eles podem não ser capazes de interpretar tão bem quanto o ator principal, mas sabem como cair de grandes alturas, simular cenas de grande perigo, ou o que quer que seja necessário. Como de perto o dublê precisa se parecer com o ator, os diretores escolhem alguém que o lembre vagamente em altura e peso. A mesma necessidade ocorre no desenvolvimento de software. Quando não se pode usar o objeto real ao escrever o teste, usa-se um dublê.
O termo Dublês de Teste foi sugerido por Gerard Meszaros, quando trabalhava em seu livro xUnit Test Patterns (xunitpatterns.com), como um nome genérico para os objetos usados na substituição de objetos reais.
Isolamento do Comportamento
Em um software, as classes dificilmente funcionam isoladamente e frequentemente se comunicam com outros elementos da aplicação. Quando construímos um teste de unidade, um dos principais desafios é exatamente isolar a classe que está sendo testada para garantir o seu comportamento.
Do ponto de vista de teste de unidade, considera-se comportamento a ação esperada ou realizada por um método de uma classe. Para garantir a eficiência deste comportamento é preciso observá-lo de maneira isolada, ou seja, garantir que objetos externos não alterarão o resultado. Para que isto seja possível, estas influências devem de alguma forma ser controladas. Quando não se tem este controle e ocorre um erro durante a execução de um teste, torna-se difícil saber ao certo se a causa está na unidade em teste ou nos objetos relacionados.
Tipos de Dependências
Considera-se dependência, um objeto do sistema que a unidade em teste interage e sobre o qual não possui controle. Por exemplo: uma classe, um serviço, um banco de dados, etc.
As dependências podem ser de dois tipos: entradas e saídas indiretas. As entradas indiretas são dados que a unidade de teste obtém de algum objeto do qual ela depende. Veja um exemplo deste tipo de dependência na Listagem 1. Este código trata da emissão de uma nota fiscal, e neste caso, faz-se necessário gravar o usuário que efetuou a operação de faturar. No entanto, em sistemas que exigem o controle de acesso, é comum ter um serviço que disponibiliza as informações do usuário (linha 9). Desta forma, pode-se afirmar que o método faturar() depende deste serviço (seguranca), ou seja, de uma entrada indireta.
"
Este é um post disponível para assinantes MVP
Que os projetos de desenvolvimento de software falham ou têm algum tipo de falha, já sabemos. Mas o que poucas pessoas têm conhecimento é que erros, conhecidos como “bugs”, custam muito caro às empresas e a seus clientes. Uma pesquisa feita pela Gartner revela que este custo chega a cerca de 60 bilhões de dólares por ano nos Estados Unidos. A justificativa para tanto prejuízo está no fato de grande parte destas falhas serem resolvidas tardiamente, quando o software já está em produção. A pesquisa informa ainda, que o processo utilizado para o desenvolvimento dos softwares reflete na qualidade final do produto.
De uma forma geral, o processo de desenvolvimento de software pode ser enxergado como uma metodologia ou conjunto de práticas que auxiliam a produção de um software. Essas práticas culminam em um produto que reflete a forma como todo o processo foi conduzido.
Uma prática muito comum em equipes ágeis é utilizar o TDD, ou Desenvolvimento Orientado por Testes, que ganhou tremenda popularidade nos últimos anos. No entanto, o uso desta técnica fica limitado por diversos fatores, tais como: falta de conhecimento do time, arquitetura mal elaborada, código legado e, principalmente, dependências internas e externas (outras classes, serviços, banco de dados, etc.).
Com base nisso, neste artigo apresentaremos algumas formas de resolver facilmente o problema com as dependências utilizando Dublês de Teste, que simulam o comportamento de objetos reais de forma controlada.
Dublês de Testes
Quando a indústria do cinema quer filmar algo que exige um nível mais especializado de formação e/ou capacidade física para o ator principal, eles contratam um “dublê” para tomar o lugar na cena. O dublê é um indivíduo altamente treinado, capaz de atender aos requisitos específicos da cena. Eles podem não ser capazes de interpretar tão bem quanto o ator principal, mas sabem como cair de grandes alturas, simular cenas de grande perigo, ou o que quer que seja necessário. Como de perto o dublê precisa se parecer com o ator, os diretores escolhem alguém que o lembre vagamente em altura e peso. A mesma necessidade ocorre no desenvolvimento de software. Quando não se pode usar o objeto real ao escrever o teste, usa-se um dublê.
O termo Dublês de Teste foi sugerido por Gerard Meszaros, quando trabalhava em seu livro xUnit Test Patterns (xunitpatterns.com), como um nome genérico para os objetos usados na substituição de objetos reais.
Isolamento do Comportamento
Em um software, as classes dificilmente funcionam isoladamente e frequentemente se comunicam com outros elementos da aplicação. Quando construímos um teste de unidade, um dos principais desafios é exatamente isolar a classe que está sendo testada para garantir o seu comportamento.
Do ponto de vista de teste de unidade, considera-se comportamento a ação esperada ou realizada por um método de uma classe. Para garantir a eficiência deste comportamento é preciso observá-lo de maneira isolada, ou seja, garantir que objetos externos não alterarão o resultado. Para que isto seja possível, estas influências devem de alguma forma ser controladas. Quando não se tem este controle e ocorre um erro durante a execução de um teste, torna-se difícil saber ao certo se a causa está na unidade em teste ou nos objetos relacionados.
Tipos de Dependências
Considera-se dependência, um objeto do sistema que a unidade em teste interage e sobre o qual não possui controle. Por exemplo: uma classe, um serviço, um banco de dados, etc.
As dependências podem ser de dois tipos: entradas e saídas indiretas. As entradas indiretas são dados que a unidade de teste obtém de algum objeto do qual ela depende. Veja um exemplo deste tipo de dependência na Listagem 1. Este código trata da emissão de uma nota fiscal, e neste caso, faz-se necessário gravar o usuário que efetuou a operação de faturar. No entanto, em sistemas que exigem o controle de acesso, é comum ter um serviço que disponibiliza as informações do usuário (linha 9). Desta forma, pode-se afirmar que o método faturar() depende deste serviço (seguranca), ou seja, de uma entrada indireta.
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
O que você achou deste post?
Cursos relacionados
Publicidade
