May 17

ColdFusion 10 Family

Permanent link to this article: http://ensina.me/coldfusion/coldfusion-10-family/

May 17

Build Applications Quickly with ColdFusion 10

Permanent link to this article: http://ensina.me/coldfusion/build-applications-quickly-with-coldfusion-10/

May 17

Estudo de Caso, Programação Orientada a Domínio

Quando falamos de Programação Orientada ao Domínio ou Problema como achar melhor, costuma passar um entendimento meio superficial do assunto.

Então, resolvi escrever de uma forma mais prática sobre o assunto e implementar umas soluções baseadas em Programação Orientada a Domínio.

Para começar vamos definir que teremos uma nova camada em nossa aplicação. E esta camada será chamada de Domain.

Vamos no diagrama abaixo como ficaria nossas camadas de programação.

Diagrama

Na camada Domain ficarão nossos problemas, a ideia é transferir os problemas de implementação da nossa lógica de negócio para a camada de Domínios.

Dessa maneira reduziremos nossos códigos na camada de negócio bruscamente, além de conseguir implementações mais limpas.

Como implementar

Não usaremos framework nenhum e sim, implementaremos nossa camada de domínio com código próprio para entendermos a resolução do problema em si e assim entenderemos muito melhor como funciona esse conceito.

Vamos abordar somente a parte da camada de negócios, não vamos ver consultas em banco propriamente e sim trabalhar com as chamadas e em resultados imaginários. Pois dessa forma conseguiremos um artigo prático e não muito grande.

Vamos começar

Para criarmos nossa prática, vamos criar um cenário de refactoring, onde temos uma camada de lógica e refatoraremos a mesma inserindo o conceito de orientação a domínios.
Read the rest of this entry »

Permanent link to this article: http://ensina.me/coldfusion/estudo-de-caso-programacao-orientada-a-dominio/

May 10

TDD com ColdFusion – Parte 3 (Criando um Teste com o MXUnit)

Vamos ver na prática como trabalhar com TDD no ColdFusion.

Caso você não saiba sobre TDD e/ou MXUnit, aconselho a ler primeiramente os seguintes posts:

– TDD – Desenvolvimento Guiado por Testes;
– TDD com ColdFusion – Parte 1 (Instalação do MXUnit);
– TDD com ColdFusion – Parte 2 (Configuração do MXUnit);
– MXUnit – funções setUp() e tearDown().

Para exemplificar vamos criar uma Calculadora com as 4 operações básicas. O ideal para escrever os testes unitários é utilizando um ciclo de Desenvolvimento, tal como:

– Criar o teste;
– Executar o teste;
– Escrever o código propriamente dito;
– Executar os testes novamente e ajustar o código até passarem sem erro;
– Refatorar; e
– Repetir este ciclo.
Read the rest of this entry »

Permanent link to this article: http://ensina.me/coldfusion/tdd-com-coldfusion-parte-3-criando-um-teste-com-o-mxunit/

May 10

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

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:

<cfcomponent displayname="MeuComponenteTest"
  extends="mxunit.framework.TestCase"
  hint="Componente exemplo de teste">

<cffunction name="setUp" access="public" returntype="void">
  <!--- Instancia o componente que queremos testar
        e faz os set's necessários antes da execução dos casos de teste --->
  <cfset this.objTeste = createObject("component","Usuario").init() >
  <cfset this.objTeste.setNome("Anderson Straube") />
  <cfset this.objTeste.setEmail("[email protected]") />
</cffunction>

<!--- ...seus testes aqui... --->

<cffunction name="tearDown" access="public" returntype="void">
  <!--- Aqui eu limpo a variável "objTeste" --->
  <cfset this.objTeste = "" >  
</cffunction>
</cfcomponent>

Nosso componente herda a classe TestCase do framework (extends=”mxunit.framework.TestCase”), então o método setUp() é chamado, depois nosso método de teste e então tearDown().

Vale ressaltar que os métodos setUp() e o tearDown() são executados para cada caso de teste.

A idéia é que quando você precisa testar algo, o objeto deve estar em um estado conhecido, então o setUp faz isso, configura o objeto ao estado inicial desejado e normalmente o tearDown irá limpá-lo, uma vez que o objeto pode ter seu estado alterado em algum teste executado.

Até a próxima.

por Anderson Straube
Post original

Permanent link to this article: http://ensina.me/coldfusion/mxunit-funcoes-setup-e-teardown/

May 10

TDD com ColdFusion – Parte 2 (Configuração do MXUnit)

Continuando a série de posts sobre TDD (Test Driven Development), antes de partir para a prática precisamos configurar o MXUnit (framework para teste unitário em CFML).

Se você não sabe o que é TDD veja nesse link.

Precisamos do MXUnit instalado no Eclipse e no seu projeto, caso não saiba como fazer
veja aqui.

Para que possamos rodar os testes precisamos configurar nossa IDE (no caso o Eclipse) para informar qual é a URL do Facade do framework, ou seja, informamos o caminho da camada de acesso (fachada) para que ele execute todos os testes.

Dentro do Eclipse selecione o projeto (aba Navigator), clique com o botão direito e vá em “Properties”, depois menu “MXUnit Properties”, em seguida insira a URL onde colocou os arquivos do framework, normalmente será a raiz do projeto, exemplo: http://seu_site.com.br/mxunit/framework/RemoteFacade.cfc?wsdl. Em “component root” insira o path dos seus arquivos de teste (nesse caso se os componentes não estiverem visíveis na web você pode criar um mapping para eles). Veja na imagem abaixo:

MXUnit Configuration

Feito isso clique no botão “Test Facade URL” para certificar de que tudo esteja funcionando.

Por ora é isso, no próximo post sobre TDD nós veremos um exemplo prático.

Até a próxima.

por Anderson Straube
Post original

Permanent link to this article: http://ensina.me/coldfusion/tdd-com-coldfusion-parte-2-configuracao-do-mxunit/

May 10

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

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:///mxunit/index.cfm. Deve aparecer uma tela semelhante à abaixo:

MXUnit Install

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):

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
Post original

Permanent link to this article: http://ensina.me/coldfusion/tdd-com-coldfusion-parte-1-instalacao-do-mxunit/

May 10

TDD – Desenvolvimento Guiado por Testes

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!”.

por Anderson Straube
Post original

Permanent link to this article: http://ensina.me/coldfusion/tdd-desenvolvimento-guiado-por-testes/

May 07

Modelo Anêmico

Um dos fundamentos da Orientação a Objetos é a não exposição dos detalhes de implementação de um objeto. Já falei algumas vezes disso nos meus artigos.

Por isso usamos o encapsulamento da implementação, dessa forma não expomos nossos objetos e temos uma melhor manutenibilidade das nossas classes e já que esse encapsulamento garante a integridade de nossos objetos podemos garantir também que o usuário só consiga acessar nossos objetos através de um contrato definido com uma interface publica.
Read the rest of this entry »

Permanent link to this article: http://ensina.me/coldfusion/modelo-anemico/

May 07

Domain-Driven Design

Quando vamos desenvolver um software, sabemos que esse software é para atender alguma necessidade de alguém. Essa necessidade para quem solicitou o software pode ser caracterizado como um problema. Com isso concluímos que um software serve para resolver um problema. Todas as necessidades em volta do problema podemos denominar de Domínio.

Com isso, o nome Domain-Drive Design poderia ser traduzido para: Guiar o Design da Aplicação pelo Domínio ou quem sabe: Programação Orientada a Domínios(Problemas).

Esse conceito envolve muito mais informação do que códigos é um padrão mais conceitual do que prático.

O que vemos em nosso dia-a-dia, é desenvolvimento de softwares guiados a qualquer coisa, menos pelo domínio.

É familiar o desenvolvimento de um software inteiro e na hora do cliente homologar, ele pedir um monte de mudanças?

Quando a mudança é algo que não existia… é uma coisa, agora quando a mudança é: “Esse campo não tinha que ser texto aberto e sim comboBox.” você percebe que houve falha no processo. Ou quando o cliente diz: “Esse módulo de processamento financeiro está errado, os valores não batem.” Bom, agora você tem um problema novo.

Esse tipo de situação pode ser evitada se guiarmos nosso desenvolvimento pelo Domínio.
Read the rest of this entry »

Permanent link to this article: http://ensina.me/coldfusion/domain-driven-design/

Older posts «

» Newer posts