SocketTimeoutException no MXUnit – Configurando o timeout para o teste

On 9 de outubro de 2014, in CFML, TDD, by andersonstraube

Se você precisa executar um teste unitário que demore, por exemplo: uma leitura de um arquivo grande, uma requisição http ou qualquer outra operação demorada certamente vai ocorrer o seguinte erro no MXUnit:

java.net.SocketTimeoutException: Read timed out; Is the timeout preference
too low? Are you dumping/calling debug() on large data or cfc instances?

Continue reading »

Tagged with:  

MXUnit – funções setUp() e tearDown()

On 16 de fevereiro de 2012, in CFML, TDD, by andersonstraube

Continuando a série de posts sobre TDD (Test Driven Development), vamos explorar os métodos “setUp()” e “tearDown()”.

Na maioria dos frameworks de testes unitários temos esses dois métodos para a configuração do nosso teste:

setUp()

Este método é utilizado no início do processo de teste, ou seja, antes de executar cada teste nós preparamos o cenário com configurações anteriores a execução de cada caso de teste.

tearDown()

Este método é utilizado no final de cada caso de teste, ou seja, ele desfaz o que o setUp() criou.

Vamos ver na prática como utilizá-los:

Continue reading »

Tagged with:  

TDD com ColdFusion – Parte 1 (Instalação do MXUnit)

On 15 de fevereiro de 2012, in TDD, by andersonstraube

Salve pessoal.

Começarei uma série de posts sobre TDD (Test Driven Development) com ColdFusion.

Como de início não poderia ser diferente, vamos começar com a instalação do framework de teste bem como o plugin para o Eclipse.

*Existem vários frameworks para teste unitário em CFML, no entanto para os exemplos utilizarei o MXUnit por ser muito simples, prático e funcional.

Why MXUnit?
At its core, MXUnit grew around the concept of making things easier for the person writing the tests. We believe people shy away from unit testing because the perception (sometimes justified!) is that it’s too inconvenient. We sought to change that.

Instalação do Framework:

1 ) Baixe a última versão do MXUnit => (https://github.com/downloads/mxunit/mxunit/mxunit-2.1.1.zip);

2) Descompacte o conteúdo dentro do webroot (“domínio/mxunit”);

3) Teste a instalação no http://<seu_servidor>/mxunit/index.cfm. Deve aparecer uma tela semelhante à abaixo:

Instalacao MXUnit

Instalação do Plugin para Eclipse:

1) Com o Eclipse aberto, clique no menu “Help > Install New Software”;

2) Clique em Add e depois insira o Nome e Location respectivamente: mxUnit e http://mxunit.org/update (conforme imagem abaixo):

Instalação Plugin MXUnit

3) Feito isso clique em “OK” e siga o trivial “NNF” (next -> next -> finish);

Nos próximos posts pretendo explorar a parte de codificação.

Até a próxima.

Att,
Anderson Straube

Tagged with:  

TDD – Desenvolvimento Guiado por Testes

On 15 de fevereiro de 2012, in Desenvolvimento, by andersonstraube

Desenvolvimento Guiado por Testes (Test Driven Development), ou simplesmente TDD, consiste numa técnica de desenvolvimento de software onde primeiro são criados os testes abrangendo a melhoria desejada e/ou novas funcionalidades e somente depois é implementado o código necessário para passar por eles. A disponibilidade de testes antes do código propriamente dito garante um desenvolvimento rápido e um feedback sobre qualquer mudança. Não somente maximiza a qualidade do seu código, como também simplifica o processo de desenvolvimento além do aumento da produtividade.
O TDD é uma das práticas do XP (Extreme Programming), e foram formuladas por Kent Beck e Ron Jeffries a partir de suas experiências. O Extreme Programming (XP) é uma metodologia de desenvolvimento de software que visa criar sistemas de melhor qualidade e produzidos em menos tempo. As idéias gerais por trás do XP são simplificar o processo de desenvolvimento de software e manter um processo contínuo de desenvolvimento em um ciclo curto, ou seja, desenvolver entregáveis em períodos curtos (iterações) que forneçam um feedback constante do estado do software.  (Nos próximos post’s pretendo abordar a filosofia e algumas práticas do XP).

Vejamos como é o ciclo do TDD:

  1. Crie um teste: cada nova funcionalidade deve começar com um teste escrito. Este teste deve falhar antes mesmo da funcionalidade ser implementada. Por isso é importante conhecer claramente os requisitos e especificações da nova funcionalidade. (Isso também vale para correção de bug’s onde se deve sempre escrever os testes primeiro, para só então alterar o código propriamente dito).
  2. Execute todos os testes: você saberá que a rotina de testes está funcionando corretamente e que o novo teste não passou sem que o teste da funcionalidade tenha sido implementada.
  3. Escreva o código: escreva o código que irá passar naquele teste que você criou na etapa anterior. Não se preocupe muito com o “design” do código neste momento, é muito importante que este código implementado reflita somente o teste escrito.
  4. Execute novamente todos os testes: se todos os testes passarem, você terá certeza que o código atende todos os requisitos testados e que esta nova funcionalidade não afetou outras partes do sistema.
  5. Refatore o código: vá ajustando/otimizando o código se for necessário. Lembre-se de executar os testes constantemente durante esta etapa, pois só assim saberá se o sistema não foi modificado da maneira incorreta. Mantenha o hábito da refatoração constante em seus códigos e não tenha medo das mudanças, afinal os testes existem para isso.

TDD é um processo iterativo e você repete estes passos inúmeras vezes até que fique satisfeito com o novo código.

A maneira que o TDD trabalha é através de requisitos, ou casos de uso que são decompostos em um conjunto de comportamentos que são premissa para atender o requisito. Para cada comportamento do sistema, a primeira coisa a se fazer é escrever um teste unitário que irá testar este comportamento. O teste unitário primeiro, portanto temos um conjunto bem definido de critérios que podemos utilizar para mensurar a quantidade de código necessário que foi escrito para implementar este comportamento. Um dos benefícios de se escrever o teste primeiro é que ele ajuda a definir o comportamento do sistema de uma maneira mais clara e responder algumas perguntas do modelo.

Quando se implementa testes unitários depois do código estar pronto, você tende a implementar testes de baixa qualidade, pois você inconscientemente escreve um teste para rodar no código produzido, e o correto seria o contrário, seu código é que deveria passar no teste previamente implementado.

Os testes, quando devidamente escritos, oferecem uma certa “garantia” de que a aplicação está funcionando da maneira como deveria.

E não esqueça: “Se testar é bom, vamos testar toda hora!”.

Tagged with: