Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Easy .net magazine
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Testes Unitários - Revista easy .Net Magazine 22
Este artigo trata de conceitos que estão relacionados direta ou indiretamente com testes unitários. Veremos a definição, como funcionam e como criar testes unitários para seus projetos.
Easy .net magazine 22
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Easy .net magazine 22
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Easy .net magazine 22
De acordo com o Aurélio teste significa, dentre outras coisas, “Prova, verificação da eficiência ou bom funcionamento (de máquinas, materiais etc.)”.
Em toda indústria a questão dos testes é de suma importância para a qualidade final dos produtos desenvolvidos. Usemos a indústria automobilística como exemplo.
• O veículo passa por um “crash test” para avaliar o acionamento do air bag.
• O veículo passa por um teste de velocidade para avaliar o funcionamento dos componentes internos do motor.
• O veículo passa por um teste no túnel de vento para avaliar a desempenho aerodinâmico do mesmo.
Pois bem, a indústria de software, assim como as demais, possui diversas técnicas e metodologias empregadas para garantir a qualidade e o bom funcionamento do mesmo. Por exemplo, testes funcionais, testes de carga etc.
Enfim, existe uma infinidade de tipos e técnicas de testes de software, cada uma com o seu propósito. Alguns destes testes devem ser executados por “testes”, outros por usuários comuns e outros pelo próprio desenvolvedor, como é o caso do teste unitário, que veremos neste artigo.
Testes Unitários
O teste unitário é o teste de menor nível no desenvolvimento de software, ou seja, com ele testamos as menores estruturas que temos em nossos softwares, que são os métodos.
Sendo assim, quando estamos falando de testar unitariamente o software, estamos falando em criar métodos para testar os comportamentos de nosso sistema. Por exemplo, se temos um método somar, teríamos o método de testes “somarTest”.
Quando escrevemos um teste unitário para um método, desejamos garantir que o comportamento do mesmo seja exatamente como o esperado nas mais variadas possibilidades. A ideia é pegar os bugs logo que eles nasçam. Além disso, o teste unitário se torna um ativo do projeto, ou seja, pode ser reutilizado e executado diversas vezes sem onerar o seu tempo.
Testes unitários e TDD são coisas diferentes
Um equívoco muito comum que vejo as pessoas cometerem no início de seus estudos sobre testes unitários é a confusão com TDD. No início muita gente acha que escrevendo testes unitários está desenvolvendo orientado a testes.
TDD é mais do que uma técnica, é um processo de desenvolvimento onde todo código novo da aplicação é escrito a partir de um teste falho, ou seja, você primeiro escreve um teste sem que exista o recurso, este teste obviamente falhará, somente então você escreve a implementação do recurso.
Este processo possui três passos simples, conhecidos como Red, Green, Refactor, onde:
• Red: você escreve o teste sem existir o código. Logo ele falhará.
• Green: implementa a solução, escrevendo o código necessário para que o teste passe.
• Refactor: refatora a solução dada no item dois, de acordo com as boas práticas de programação.
Nota do Devman
Refatoração é uma boa prática de desenvolvimento que consiste em uma série de técnicas para melhorar a qualidade e legibilidade do código sem afetar o comportamento conhecido do sistema.
Pois bem, é preciso entender que testes unitários e TDD estão intimamente relacionados, porém são coisas bem diferentes. O fato de você usar testes unitários não significa que você use TDD.
Uma das diferenças chaves, é a ótica do tempo em que são realizados os testes. Se você implementa seu código e depois cria seus testes, você simplesmente usa testes unitários. Agora, a partir do momento em que você começa a escrever seus testes antes mesmos de implementar a solução que eles testarão, aí você está mais próximo do TDD.
Porém, o ponto fundamental é a motivação das duas técnicas. Enquanto testes unitários têm como objetivo principal garantir que cada parte do sistema tenha exatamente o comportamento esperado, o TDD tem como motivação principal o design do código. Um dos grandes benefícios do uso do TDD é o design da solução. Quando se pensa na ótica do consumidor do código antes mesmo do código existir, você se obriga a pensar e avaliar as melhores e mais simples formas de implementação da solução, o que traz um grande benefício para o design da solução.
Nota do Devman
"
Este é um post disponível para assinantes MVP
Em toda indústria a questão dos testes é de suma importância para a qualidade final dos produtos desenvolvidos. Usemos a indústria automobilística como exemplo.
• O veículo passa por um “crash test” para avaliar o acionamento do air bag.
• O veículo passa por um teste de velocidade para avaliar o funcionamento dos componentes internos do motor.
• O veículo passa por um teste no túnel de vento para avaliar a desempenho aerodinâmico do mesmo.
Pois bem, a indústria de software, assim como as demais, possui diversas técnicas e metodologias empregadas para garantir a qualidade e o bom funcionamento do mesmo. Por exemplo, testes funcionais, testes de carga etc.
Enfim, existe uma infinidade de tipos e técnicas de testes de software, cada uma com o seu propósito. Alguns destes testes devem ser executados por “testes”, outros por usuários comuns e outros pelo próprio desenvolvedor, como é o caso do teste unitário, que veremos neste artigo.
Testes Unitários
O teste unitário é o teste de menor nível no desenvolvimento de software, ou seja, com ele testamos as menores estruturas que temos em nossos softwares, que são os métodos.
Sendo assim, quando estamos falando de testar unitariamente o software, estamos falando em criar métodos para testar os comportamentos de nosso sistema. Por exemplo, se temos um método somar, teríamos o método de testes “somarTest”.
Quando escrevemos um teste unitário para um método, desejamos garantir que o comportamento do mesmo seja exatamente como o esperado nas mais variadas possibilidades. A ideia é pegar os bugs logo que eles nasçam. Além disso, o teste unitário se torna um ativo do projeto, ou seja, pode ser reutilizado e executado diversas vezes sem onerar o seu tempo.
Testes unitários e TDD são coisas diferentes
Um equívoco muito comum que vejo as pessoas cometerem no início de seus estudos sobre testes unitários é a confusão com TDD. No início muita gente acha que escrevendo testes unitários está desenvolvendo orientado a testes.
TDD é mais do que uma técnica, é um processo de desenvolvimento onde todo código novo da aplicação é escrito a partir de um teste falho, ou seja, você primeiro escreve um teste sem que exista o recurso, este teste obviamente falhará, somente então você escreve a implementação do recurso.
Este processo possui três passos simples, conhecidos como Red, Green, Refactor, onde:
• Red: você escreve o teste sem existir o código. Logo ele falhará.
• Green: implementa a solução, escrevendo o código necessário para que o teste passe.
• Refactor: refatora a solução dada no item dois, de acordo com as boas práticas de programação.
Nota do Devman
Refatoração é uma boa prática de desenvolvimento que consiste em uma série de técnicas para melhorar a qualidade e legibilidade do código sem afetar o comportamento conhecido do sistema.
Pois bem, é preciso entender que testes unitários e TDD estão intimamente relacionados, porém são coisas bem diferentes. O fato de você usar testes unitários não significa que você use TDD.
Uma das diferenças chaves, é a ótica do tempo em que são realizados os testes. Se você implementa seu código e depois cria seus testes, você simplesmente usa testes unitários. Agora, a partir do momento em que você começa a escrever seus testes antes mesmos de implementar a solução que eles testarão, aí você está mais próximo do TDD.
Porém, o ponto fundamental é a motivação das duas técnicas. Enquanto testes unitários têm como objetivo principal garantir que cada parte do sistema tenha exatamente o comportamento esperado, o TDD tem como motivação principal o design do código. Um dos grandes benefícios do uso do TDD é o design da solução. Quando se pensa na ótica do consumidor do código antes mesmo do código existir, você se obriga a pensar e avaliar as melhores e mais simples formas de implementação da solução, o que traz um grande benefício para o design da solução.
Nota do Devman
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Easy .net magazine
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Ricardo Da Silva Coelho
Graduado em Analise de Sistemas, Pós-graduando em Engenharia de software, mais de 7 anos de experiência em desenvolvimento de software, onde atuou em projetos de diversos seguimentos como varejo, telecomunicações, ERPs etc e nas mais variadas plataformas(Desktop, Web e Mobile). Articulista do portal...
O que você achou deste post?
3 COMENTÁRIOS
Joao Arthur Juaçaba Moreira.
este foi um dos melhores artigos que já li na easy .NET parabéns muito bom mesmo
[há +1 mês] -
Responder
Wesley Yamazack
Opa Joao, concordo com você 110%!!!!
Minha opinião, o Ricardo Coelho é excepcional!!! Parabéns Ricardo muito sucesso pra ti!
Um abraço
Minha opinião, o Ricardo Coelho é excepcional!!! Parabéns Ricardo muito sucesso pra ti!
Um abraço
[há +1 mês] -
Responder
Davi
ótimo artigo Ricardo, obrigado e parabéns!
[há +1 mês] -
Responder
Cursos relacionados
Publicidade
