Padrões

JSON Simples e Prático, Parte I

Fala pessoal!

Esta semana percebi que muitos ainda não conhecem ou continuam na dúvida sobre o que é JSON e resolvi contribuir com mais um artigo.

Afinal, o que é JSON?
JSON é basicamente um formato leve de troca de informações/dados entre sistemas. Mas JSON significa JavaScript Object Notation, ou seja, só posso usar com JavaScript correto? Na verdade não e alguns ainda caem nesta armadilha.

O JSON além de ser um formato leve para troca de dados é também muito simples de ler. Mas quando dizemos que algo é simples, é interessante compará-lo com algo mais complexo para entendermos tal simplicidade não é? Neste caso podemos comparar o JSON com o formato XML.

Vamos visualizar esta diferença?

  <?xml version="1.0" encoding="UTF-8"?>
    <id>1</id>
    <nome>Alexandre Gama</nome>
    <endereco>R. Qualquer</endereco>
  {"id":1,"nome":"Alexandre Gama", "endereco":"R. Qualquer"}

Bom, é notável a diferença. Visualmente o segundo trecho (em JSON) é mais fácil de ler. Mas só existe essa diferença entre os dois? Na verdade não. Podemos listar algumas outras vantagens:

Vantagens do JSON:
- Leitura mais simples

- Analisador(parsing) mais fácil

- JSON suporta objetos! Sim, ele é tipado!

- Velocidade maior na execução e transporte de dados

- Arquivo com tamanho reduzido

- Quem utiliza? Google, Facebook, Yahoo!, Twitter...

Estas são algumas das vantagens apresentadas pelo JSON. Agora vamos ao que interessa: Código! :)
Vamos fazer um exemplo extremamente simples nesta primeira parte e avançaremos no próximo artigo, inclusive falando sobre JSON em páginas Web.

Qual biblioteca usar?
Existem diversas bibliotecas para trabalharmos com JSON e Java. Usaremos no nosso estudo o json.jar que você pode baixar tranquilamente neste link

O nosso caso de estudo será simples: Teremos uma classe Carro que será a nossa classe POJO e a classe EstudoJSON que terá o nosso famoso método main.

Classe Carro

package br.com.json;

public class Carro {
	private Long id;
	private String modelo;
	private String placa;

	public Long getId() {
		return id;
	}
	public void setId(Long id) {
		this.id = id;
	}
	public String getModelo() {
		return modelo;
	}
	public void setModelo(String modelo) {
		this.modelo = modelo;
	}
	public String getPlaca() {
		return placa;
	}
	public void setPlaca(String placa) {
		this.placa = placa;
	}

        //Aqui fizemos o Override do método toString() para visualizar a impressão com o System.out.println()
	@Override
	public String toString() {
		return "[id=" + id + ", modelo=" + modelo + ", placa=" + placa
				+ "]";
	}

}

Esta é uma classe simples, onde temos os atributos Id, Modelo e Placa.

Agora teremos a classe EstudoJSON

package br.com.json;

import org.json.JSONArray;
import org.json.JSONException;
import org.json.JSONObject;

public class EstudoJSON {
	public static void main(String[] args) throws JSONException {
		adicaoSimplesDeDados();
	}
}

Repare que criamos o método adicaoSimplesDeDados() que conterá o código de exemplo:

private static void adicaoSimplesDeDados() throws JSONException {
    //Criação do objeto carro e atribuição dos valores
	Carro carro = new Carro();
	carro.setId(1l);
	carro.setModelo("Celta");
	carro.setPlaca("AAA1234");

    //Criação do objeto carroJson
	JSONObject carroJson = new JSONObject();
    //Inserção dos valores do carro no objeto JSON
	carroJson.put("id", carro.getId());
	carroJson.put("Modelo", carro.getModelo());
	carroJson.put("Placa", carro.getPlaca());

    //Impressão do objeto JSON
	System.out.println(carroJson);
}

Se executarmos este código, veremos que foi impresso no console o seguinte:

{"id":1,"Modelo":"Celta","Placa":"AAA1234"}

Você desenvolvedor mais atento vai reparar que existe um objeto impresso: Um Long! Isso mesmo! Como vimos, o JSON consegue armazenar objetos! Podemos inclusive armazenar um objeto do tipo Carro mesmo:

Modificamos o nosso método main:

public class EstudoJSON {
	public static void main(String[] args) throws JSONException {
		adicaoSimplesDeDados();

        adicaoDeUmObjeto();
	}
}

E adicionamos o método adicaoDeUmObjeto():

private static void adicaoDeUmObjeto() throws JSONException {
	Carro carro = new Carro();
	carro.setId(1l);
	carro.setModelo("Celta");
	carro.setPlaca("AAA1234");

	JSONObject carroJson = new JSONObject();
    //Adição do objeto carro
	carroJson.put("Carro", carro);

	System.out.println(carroJson);
}

Neste caso foi impresso no console o seguinte:

{"Carro":"[id=1, modelo=Celta, placa=AAA1234]"}

Simples não?
Como o JSON trabalha com coleção de pares nome/valor, podemos imprimir um valor específico simplesmente chamando o nome que desejamos.

System.out.println(carroJson.get("Modelo"));

Veja que neste caso queremos somente o modelo do carro, bastando fazer a chamada get("nome que desejamos")!

Conclusão
É isso pessoal! Vimos as vantagens do JSON e vimos como é simples começar a trabalhar com ele. Nos próximos artigos veremos exemplos mais complexos e veremos algo mais real onde faremos chamadas à API do Facebook!

Você também pode encontrar este código no meu Gist Público.

Abraços!

MVC simples e prático, Parte I

Fala pessoal!

Sim, assunto batido! Model View Controller! Mas é muito comum encontrarmos pela internet tutoriais um pouco estranhos, visões às vezes que parecem particulares, diagramas errados e alguns ainda com dúvidas.

O conceito do MVC é extremamente simples mas a sua visualização não é lá tão trivial assim. O artigo tem 2 objetivos principais: Relembrar a teoria e mostrar uma visualização simplificada do conceito.

Então vamos lá!

Entendendo o papel do M – Model

Pessoal, a idéia é simples: Quando pensamos em regras de negócio, estamos pensando no Modelo da aplicação. Basicamente é isto. No Model podemos ter validações, acesso a banco, acesso à arquivos, cálculos, etc.

O usuário, por exemplo, coloca um produto em um carrinho de compras e é no Model que faremos o cálculo final do pedido(descontos, juros), que validaremos a conta do usuário, que calcularemos o frete, que validaremos o endereço e por aí vai.

Mas como o usuário seleciona um produto em um carrinho de compras por exemplo? Como insere um Endereço para a entrega? Na View!

Entendendo o papel do V – View

A View só existe por um único motivo: Mostrar dados! Na prática isso nunca muitas vezes não acontece, mas deveria! Você que já desenvolveu em Delphi/VB com toda certeza já viu regras em um botão. Você que já desenvolveu em Java também já viu centenas de regras nas páginas JSP ou espalhadas em Servlets que criam as páginas. Isso é feio! O dia que precisarmos mudar de JSP para JSF ou GWT simplesmente não mudaremos!

Mas e agora? Entendido o conceito básico do Model, como a View passa os valores digitados/selecionados para o Model? Passa direto? Não!

Entendendo o papel do C – Controller

Aqui temos um maestro! Temos regras de negócio no Controller? Não! Temos visualização no Controller? Não! O Controller simplesmente delega para o Model as solicitações da View. O Controller é burro no sentido de regras de negócio da aplicação. Ele é responsável por saber quem está pedindo algo e a quem enviará este algo!

O Controller conhece a View e conhece o Model mas o Model não conhece a View, porém a View observa o Model e este avisa quando seus dados foram atualizados, para a View mostrá-los.

Ok! Depois dessa frase bagunçada, nada como um pequeno esquema para entendermos melhor:

Diagrama MVC

Entendendo o MVC

Veja como é simples com o diagrama acima:

O Controller conhece a View e conhece o Model. Isto porque ele recebe as requisições do usuário da View e envia para o Model fazer algo com estas requisições. Exemplo: O usuário quer saber o endereço de uma residência a partir de um cep digitado.

O Model simplesmente recebe a requisição, faz toda a mágica (persiste dados, valida informações, etc) e fica com os dados prontos (atualizados) para serem visualizados novamente pela View.

A View fica observando o Model e quando este é atualizado, a View mostra os dados atualizados para o usuário.

E o Model acaba não conhecendo ninguém!

Legal! E por que eu trabalharia desta forma?

Porque, além de elegante, é profissional! Mas se você não se convenceu com estes argumentos, podemos ter outro: é Seguro! Temos aqui uma separação bem clara entre a Visualização e as Regras de Negócio. Caso você queira modificar uma regra, como um cálculo de juros, você precisaria apenas modificar o seu Model (e espero que em um só local! =) )  e não precisaria se preocupar com a visualização.

O mesmo vale para a View. Caso você queira modificar uma tela inteira, não precisaria se preocupar com as regras e sim somente com a tela.

Um outro motivo muito forte é que você pode querer disponibilizar os seus métodos em um WebService por exemplo e com uma separação clara do seu modelo, isso seria facilitado, e muito! Imagine que você tenha uma aplicação Web e outra Desktop (JSF e Swing por exemplo) mas que façam a mesma coisa. Seria muito ruim ter funcionalidades iguais nos dois ambientes pois teríamos que manter as duas iguais. Uma forma seria disponibilizar as funcionalidades em um ponto único e acessá-las nas duas aplicações. Com uma separação clara do modelo poderíamos disponibilizar estas funcionalidades por um WebService, Rest, EJB, etc.

Finalizando

O MVC é um padrão de arquitetura que existe, a grosso modo, para facilitar a manutenção da nossa aplicação, facilitar a adição de funcionalidades e facilitar a testabilidade da aplicação.

Se você ainda escreve regras de negócio nas suas páginas/forms, tente desenvolver com este padrão e veja a diferença na manutenção e na adição de funcionalidades.

No próximo post veremos um exemplo simples de implementação de uma funcionalidade utilizando o padrão MVC e veremos como é simples melhorarmos a nossa aplicação deixando-a profissional.

É isso pessoal! Abraços!

Inversão de Controle x Injeção de Dependência

Fala pessoal!!!

Com este breve artigo(breve mesmo!) vou falar sobre o conceito de Inversão de Controle, que muitos confundem com Injeção de Dependência. É justo, já que no primeiro momento os dois conceitos são bem parecidos.

O que é a Inversão de Controle (IoC)?
Basicamente, a Inversão de Controle é uma forma diferente que temos para manipular o controle sobre um objeto. É um padrão. Gosto de pensar na Inversão de Controle como sendo a mudança de conhecimento que uma classe tem em relação à outra.

Gosto de ver um trecho teórico com um trecho de código, então vamos ver desta forma!

Vamos imaginar uma classe bem simples, onde precisamos gravar um Log em um arquivo após Vender um Produto.
Então podemos ter a seguinte classe bem simples:

public class VendaDeProduto {
	public void vendeProduto(Produto produto) {
	    //Todo o código para a venda do produto...
	    Log log = new Log("Arquivo.txt");
	    log.grava(produto);
	}
}

Mas qual o problema?
Razoável o exemplo. Uma classe facilmente encontrada em qualquer código. Eu sou ruim para perceber problemas em uma classe só de vê-la, então vou imaginar uma situação real: Percebemos que a classe Log precisa do arquivo onde será gravado o Log correto? Agora vamos imaginar que o nome do arquivo será mudado para "ArquivoLog.txt"! Muito fácil, basta mudar o nome correto? Vamos então abrir a classe VendaDeProduto e mudar!

Putz! Aqui que está o problema! O que a classe de Venda tem a ver com isso? Na verdade, nada! Ou pelo menos não deveria ter. Para uma modificação na classe Log fomos obrigados a modificar algo dentro da classe de Venda e isso não é legal. Neste momento foi fácil modificar, mas e se tivéssemos 30 classes utilizando a classe Log? Quais as chances de esquecermos uma?

No pequeno exemplo acima vimos um detalhe importante: A classe VendaDeProduto sabe demais sobre a classe Log. A classe VendaDeProduto sabe criar a classe Log. Pior, a classe de vendas sabe que a classe Log precisa do nome de um arquivo! E isso não é justo com a classe VendaDeProduto.
A responsabilidade dela é somente de fechar uma venda. Portanto podemos ver um alto acoplamento de classes neste minúsculo código.

Um problema mais a fundo
Pra você que desenvolve com TDD, como faríamos por exemplo para fazer um teste com a classe VendaDeProduto quando precisarmos "mocká-la"? Simplesmente não conseguimos, justamente por ela criar o objeto Log! E não vale você que conhece o PowerMock inventar algo! :)

Resolvendo o problema
É aqui que entra a Inversão de Controle. Vamos literalmente inverter este controle na classe VendaDeProduto. Em vez de deixarmos a responsabilidade da criação da classe Log para a classe VendaDeProduto, vamos dar a ela esta dependência. Vamos injetar esta dependência nela. E olha o que apareceu para nós: Injeção de Dependência.

Daí muitos confundirem e acharem que os dois são a mesma coisa. Como você pode ver, vamos resolver o problema desta classe Invertendo o Controle, utilizando a Injeção de Dependência. Simples assim!

Vamos resumir: Injeção de Dependência é apenas uma forma para resolvermos a Inversão de Controle.

Temos algumas formas interessantes de Injeção de Dependência e vou falar da mais comum(em um próximo post falarei de outras!): O Constructor Injection, ou seja, injetamos uma dependência de uma classe através do construtor desta classe.

Vamos novamente exemplificar este trecho de teoria com um pouco de código. Para sermos mais coerente, vamos melhorar um pouco mais o nosso código anterior, utilizando a Injeção de Dependência!

public class VendaDeProduto {
        private Log log;

        public void VendaDeProduto(Log logVenda) {
             this.log = logVenda;
        }

	public void vendeProduto(Produto produto) {
	     //Todo o código para a venda do produto...
	     log.grava(produto);
	}
}

Olha como ficou interessante, elegante e simples! A classe VendaDeProduto precisa da classe Log para criar um Log mas neste código a classe VendaDeProduto recebeu uma instância da classe Log! Ou seja, agora ela não se preocupa mais com a criação da classe Log e simplesmente a usa.

Como a classe Log é criada agora? Não sei! E nem precisamos saber! A única coisa que precisamos é uma instância da classe Log para trabalharmos, independente de como ela foi criada!

Agora pra você que trabalha com TDD ficou muito mais simples pois basta "mockar" a classe Log, passá-la pelo construtor e fazer os testes normais da sua classe!

Finalizando
Desta forma diminuimos o acoplamente entre as nossas classes e a manutenção fica facilitada e, além de elegante, agora temos uma classe testável. Só não está mais elegante pois não estamos Injetando uma implementação de uma Interface, mas este é um assunto para outro post!

É isso pessoal, apenas uma pequena dica simples em um artigo simples para deixarmos o nosso código o mais próximo possível do que deve ser: Profissional!

Abraços pessoal!

TDD simples e prático, Parte IV

Fala Desenvolvedores!!!

Neste artigo teremos a continuação da parte III da série sobre TDD. A idéia deste artigo é continuar comentando um pouco mais sobre os Testes de Unidade e também falarmos sobre os Testes de Unidade em relação ao comportamento dos nossos objetos. Também falaremos sobre o conceito de Mock de Objetos, que é extremamente importante no TDD.

Já vou adiantar que você ficará chateado com o que faremos para “Mockar” os nossos objetos, mas prometo que em seguida ficaremos muito felizes com uma solução bem mais bacana para isso. Calma! o conceito de “Mockar” objetos aparecerá logo logo!

Para iniciar este artigo, vamos fugir um pouco do conceito citado acima e fazer a funcionalidade de divisão de dois números para verificarmos a possibilidade de fazer Testes esperando que alguma Exceção ocorra. Isso mesmo! Por algum motivo você deseja lançar uma Exceção caso algo de errado aconteça e podemos fazer isso com o JUnit, apresentado no artigo anterior.

Teste da divisão
A funcionalidade é simples: Fazer a divisão de dois números. Lembrando: É um caso simples e isolado onde a intenção é você imaginar um caso real da sua aplicação.
Então vamos para o Teste!

Mas aqui começaríamos com aquele conceito de BabySteps, onde faríamos passos curtos para chegarmos à solução, correto? Correto, porém os BabySteps não são uma regra xiita que devemos seguir à risca. Segundo o próprio Kent Beck em seu livro sobre TDD, os BabySteps são para quando realmente não temos confiança suficiente em escrever determinado código. Como ele cita também, não devemos desenvolver com BabySteps a todo momento e sim devemos ficar felizes por podermos fazê-lo quando desejarmos.

Agora que lembramos disso, vamos correr um pouquinho mais no código e escrever um pouco mais rápido que no artigo anterior, porém sinta-se à vontade para colocar a sua velocidade:

Adicionando o método de Teste à nossa classe de CalculadoraTeste:

public class CalculadoraTeste {
	@Test
	public void deveriaDividirDoisValoresPassados() throws Exception {
		int valorA = 6;
		int valorB = 2;
		Calculadora calculadora = new Calculadora();
		int divisao = calculadora.divide(valorA, valorB);

		assertEquals(3, divisao);
	}
}

E na nossa classe Calculadora, vamos escrever o nosso método de produção:

public class  Calculadora {

	public int divide(int valorA, int valorB) {
		return valorA / valorB;
	}
}

Legal! Agora podemos rodar o nosso Teste e vê-lo passando. Uma observação simples: Não comentei nos artigos anteriores mas só para ter certeza que é de conhecimento de todos, vou comentar: Rodamos os nossos Testes clicando com o botão direito na classe de Teste, selecionando Run As e em seguida selecionando o JUnit Test.

Agora temos um Teste verde na nossa frente!

Maravilha! Finalizamos? Não.

E quando esperamos por uma exceção?
Vamos atormentar os professores de matemática e fazer a seguinte alteração na nossa classe de Teste:

public class  CalculadoraTeste {
	@Test
	public void deveriaDividirDoisValoresPassados() throws Exception {
	        int valorA = 6;
  	        int valorB = 0;  //divisão por zero!
	        Calculadora calculadora = new Calculadora();
	        int divisao = calculadora.divide(valorA, valorB);

	        assertEquals(?, divisao);
	}
}

O que fizemos: atribuímos o valor zero à variável valorB. E o que esperamos no nosso assertEquals? Não tenho noção! Podemos esperar tudo, menos um valor! Sendo assim, na sua aplicação, você poderia mostrar uma mensagem para o usuário solicitando gentilmente que ele insira um valor coerente. E como podemos fazer um Teste esperando uma exceção? Vamos lá!

Teste esperando por uma exceção
Podemos usar um parâmetro na própria anotação do JUnit (@Test) para indicar qual a exceção que estamos esperando receber. Assim teríamos o seguinte código para o nosso Teste:

public class  CalculadoraTeste {

	@Test
	public void deveriaDividirDoisValoresPassados() throws Exception {
	        int valorA = 6;
		int valorB = 3;
		Calculadora calculadora = new Calculadora();
		int divisao = calculadora.divide(valorA, valorB);

		assertEquals(2, divisao);
	}

	@Test
	public void deveriaLancarUmaExcecaoIndicandoFalhaAoDividirUmNumeroPorZero()
             throws Exception {
		int valorA = 6;
		int valorB = 0;
		Calculadora calculadora = new Calculadora();
		int divisao = calculadora.divide(valorA, valorB);

		assertEquals(0, divisao);
	}
}

Mas infelizmente ao rodar, temos uma barra vermelha:

Agora sim podemos fazer o nosso Teste passar adicionando o parâmetro à anotação do JUnit (@Test):

public class CalculadoraTeste {

	@Test(expected = ArithmeticException.class)
	public void deveriaLancarUmaExcecaoIndicandoFalhaAoDividirUmNumeroPorZero()
            throws Exception {
		int valorA = 6;
		int valorB = 0;
		Calculadora calculadora = new Calculadora();
		calculadora.divide(valorA, valorB);
	}
}

E agora sim temos a barra verde para o nosso Teste:

Este foi um caso simples para mostrar como é possível trabalhar com Testes que devem verificar exceções. Podemos estender este conceito para outros momentos, como fazer um Teste que não deveria esperar uma exceção que já esta poderia ser tratada pela nossa classe Calculadora, pois fazer da forma acima não é tão interessante.

Agora vamos melhorar os nossos testes!

Indo mais além
Até agora fizemos testes bem simples e a idéia é imaginarmos outras funcionalidades em nossas aplicações reais de forma a desenvolvê-las desta forma.Claro que uma classe do tipo Calculadora não é o melhor dos exemplos, mas optei pela simplicidade até agora.

De qualquer forma, tenho certeza que sua aplicação poderá ter muitas funcionalidades que, se bem isoladas, serão também passíveis de testes semelhantes.

Agora podemos avançar um pouco mais! Começamos o artigo com uma nova palavra: "Mock".
Definição simples: Um Mock é basicamente um objeto falso, que é capaz de simular as dependências de um objeto e é capaz de simular determinadas ações desse objeto.
Por que é usado? Para testar o comportamento de outros objetos desejados.

Por que gostaríamos de testar o comportamento de outros objetos? Justamente para termos certeza de que tudo ocorreu conforme pensamos. Vamos imaginar a seguinte situação: Temos uma aplicação onde cada vez que excluímos uma pessoa, um log é gerado no banco no banco de dados com o nome da pessoa que foi excluída.

Como poderíamos ter certeza que a geração do log realmente vai ser chamada e que nada de ruim acontecerá no caminho?

Podemos fazer este teste usando exatamente um Mock da classe de Log. Vamos fazer o código mais simples que vier na nossa cabeça:

//Classe do nosso Teste
public class PessoaTeste {
	@Test
	public void deveriaCriarUmLogQuandoUmaPessoaForExcluida()
           throws Exception {
		Pessoa pessoa = new Pessoa();
		pessoa.setNome("Alexandre");
		PessoaController pessoaController = new PessoaController();
		pessoaController.exclui(pessoa);
		// Como saberemos se realmente o "criaLog" será chamado?
	}
}
//Nosso Controller
public class PessoaController {

	private PessoaDAO pessoaDAO;
	private Log log;

	public PessoaController() {
		pessoaDAO = new PessoaDAO();
		log = new Log();
	}

	public void exclui(Pessoa pessoa) {
		PessoaDAO.exclui(pessoa);
		log.criaLog(pessoa.getNome());
	}
}
//Nossa classe de criação de Logs
public class Log {

	public void criaLog(String nomeDaPessoa) {
		// Código para criar um Log no banco, em um txt, etc...
	}
}

Eu sei, eu sei. Abandonamos aqui algumas boas práticas mas é em prol de um entendimento melhor da situação. Logo logo vamos melhorar um pouco mais este código.

Voltamos à mesma pergunta: Como vamos saber se a criação do Log foi chamada? Vamos criar um Mock da nossa classe de criação de Logs!

O nosso Mock deve simular o funcionamento da funcionalidade, ou seja, ele não conterá código algum, será apenas para verificarmos se ele foi chamado.

Uma idéia seria criarmos uma classe que estende da nossa classe de Log, mas seremos um pouquinho melhores que isso e vamos criar uma Interface para implementarmos.

Assim poderíamos ter:

//Nossa Interface de criação de Logs
public interface GeradorDeLog {
	public void criaLog(String nomeDaPessoa);
}

Podemos então ter a seguinte classe horrorosa:

//Mock da nossa classe de Log
public class LogMock implements GeradorDeLog {

	private String nome;

	@Override
	public void criaLog(String nomeDaPessoa) {
		this.nome = nomeDaPessoa;
	}

	public String getNome() {
		return nome;
	}
}

Mas temos um detalhe: O nosso Controller está com uma dependência forte que é a classe Log sendo instanciada diretamente pelo Controller. Isso impossibilita o uso do nosso Mock. Então vamos melhorar um pouquinho o Design da nossa aplicação.
Opa! Olha o TDD nos "obrigando" a melhorar o Design da nossa aplicação!

Vamos então aplicar um princípio bem importante que é a Inversão de Controle através da Injeção de nossas Dependências. Vamos enviar então o nosso GeradorDeLog para o Controller através do construtor.

Assim teremos:

//Nossa classe de Teste
public class PessoaTeste {
	@Test
	public void deveriaCriarUmLogQuandoUmaPessoaForExcluida()
            throws Exception {
		Pessoa pessoa = new Pessoa();
		pessoa.setNome("Alexandre");

		LogMock nossoLogMock = new LogMock();
		PessoaController pessoaController = new PessoaController(nossoLogMock);
		pessoaController.exclui(pessoa);

		assertEquals(pessoa.getNome(), nossoLogMock.getNome());
	}
}
//Nosso Controller
public class PessoaController {

	private PessoaDAO pessoaDAO;
	private GeradorDeLog log;

	public PessoaController(GeradorDeLog log) {
		this.pessoaDAO = new PessoaDAO();
		this.log = log;
	}

	public void exclui(Pessoa pessoa) {
		PessoaDAO.exclui(pessoa);
		log.criaLog(pessoa.getNome());
	}
}

E olha que temos aqui, um teste passando!

Recapitulando: Muitas vezes precisamos testar o comportamento dos nossos objetos. No nosso caso qual é o comportamento? A criação de um Log quando uma pessoa é excluída. Mas não queremos criar um Log de verdade quando fizermos o teste de exclusão e sim queremos verificar se o método da criação do Log foi chamado.

Para fazermos isso, usamos um objeto "Mockado" que é um objeto que simula o comportamento do nosso objeto. É, a grosso modo, um objeto falso que não tem inteligência.

Assim, pelo Teste, na exclusão de uma pessoa um Log é gerado pois ao chamar o método de exclusão, o método de criação do Log também é chamado, ou seja, nada de errado acontece pelo caminho.

Para uma visão geral do nosso Teste, vamos listar os nossos passos:
- Criamos a nossa classe de Teste PessoaTeste

- Criamos as classes: PessoaController, Log, Pessoa

- Sentimos dificuldade para fazer o teste no Controller pois ele estava muito acoplado com a classe de Log

- Criamos a Interface GeradorDeLog para a nossa classe de Log implementá-la

- Fizemos a nossa classe LogMock também implementar a Interface GeradorDeLog

- Passamos para o nosso Controller a nossa classe de Log "Mockada", por Injeção de Dependência pelo construtor

- Identificamos pelo assertEquals se o método de geração de Log foi realmente invocado, verificando se o nome no Log era o mesmo nome da Pessoa

Finalizando
Legal! Conseguimos fazer o nosso Teste rodar, melhoramos um pouco o Design da nossa Aplicação aplicando a Inversão de Controle (mas podemos refatorar para algo bem melhor, claro!) mas acabamos ficando com essa classe horrorosa que é a LogMock.

Mas esta idéia não é só feia! Essa idéia só poderá ser usada caso tenhamos objetos simples. Imagine que temos um objeto que instancia outro objeto e este também instancia outro objeto e cada um tem diversos métodos. A nossa vida se resumiria a criar classes de Mock e isso não é legal.

É neste ponto que podemos usar  Frameworks para isso. Podemos "Mockar" as nossas dependências através destes Frameworks sem precisar criar outras classes para isso!

Mas este assunto é para o próximo artigo, onde trabalharemos com estas mesmas classes utilizando dois Frameworks bem bacanas do mercado!

Abraços pessoal!!!

TDD simples e prático, Parte II

Fala Desenvolvedores!!!

Dando continuidade à parte I da série continuaremos neste artigo com TDD, desta vez destrinchando um pouquinho mais a metodologia para escrevemos o nosso primeiro código.

O primeiro artigo foi bem simples, apenas uma breve introdução para apresentar os conceitos e alguns motivos para o uso da técnica do TDD.
Vamos agora avançar um pouco mais para ter uma visão melhor e um pouco mais profunda.

Sendo chato, parte I
Sei que é chato, mas ainda falarei um pouco de teoria neste início, para que realmente possamos entender (leia-se lembrar!) sobre alguns conceitos e motivos do uso de TDD.
Como havia dito, o TDD se baseia no seguinte ciclo:

Vamos entender um pouco sobre cada etapa:

Novo Teste
Este primeiro passo é o pilar do TDD (não brinca!). Temos uma nova funcionalidade do sistema e fazemos o processo inverso ao tradicional: Testamos e Codificamos e não Codificamos e Testamos.

No primeiro momento isto parece estranho, esquisito ou feio, mas não é. O fato de termos um teste primeiro que o código garante que daremos passos simples para a codificação da funcionalidade, afim de fazer o teste passar, ou seja, seremos “obrigados” a escrever uma implementação simples para que o teste passe.

No começo esta forma não é muito intuitiva e o gráfico de aprendizagem não é lá um dos melhores, mas com o tempo e aperfeiçoamento da técnica, esta será a forma mais intuitiva e segura de desenvolver que você encontrará.

Teste Falhando
Neste momento, acabamos de escrever o teste e não temos a implementação. Óbvio que o teste falhará, pois ele espera uma resposta que ainda não temos implementada em lugar algum.
Com um Teste falhando na nossa frente, temos um único objetivo na vida: Fazê-lo passar! Passamos para a próxima fase:

Nova funcionalidade
Já ouviu falar no KISS? “Keep It Simple, Stupid”, ou seja, devemos escrever o nosso código da forma mais simples possível. Código limpo, simples e funcional! Esta é a idéia.

Assim, neste momento vamos esquecer as Boas práticas, a Inversão de Controle, os Patterns, etc e  vamos codificar a nossa nova funcionalidade da forma mais simples possível para fazer o nosso Teste passar.
Neste momento estamos simplesmente escrevendo alguma funcionalidade que faça o teste passar (sem quebrar outros testes) e também teremos segurança na Refatoração deste mesmo código daqui a alguns minutos.

Vale lembrar também daquela sequência ótima de desenvolvimento que devemos ter na cabeça:
Código que funciona -> Código simples e limpo -> Código rápido

Agora com a nova funcionalidade implementada e o teste passando, seguimos para a próxima fase:

Refatoração
Agora sim! Você purista da programação que condenou a minha geração por eu ter falado para abandonarmos as boas práticas de desenvolvimento, agora sim pode ficar tranquilo!

Neste momento é que vamos analisar melhor aquele código que fizemos simplesmente para o nosso Teste passar. É neste momento que retiramos duplicidade, renomeamos variáveis, extraímos métodos, extraímos Classes, extraímos Interfaces, usamos algum padrão conhecido, etc. É neste momento que podemos deixar o nosso código simples e claro e o melhor de tudo: Funcional!

Temos um teste agora que indicará qualquer passo errado que podemos dar ao melhorar o nosso código. E não somente este código que acabamos de escrever.
Após algum tempo com TDD, será criada uma ¹Suite de Testes, onde poderemos refatorar sem a preocupação de atingir negativamente algum código já existente, pois já teremos Testes indicando qualquer falha.

Já ouviu falar no SRP? “Single Responsibility Principle”. Este princípio nos diz que devemos ter somente um motivo para modificar uma classe. Ou seja, ele fala sobre termos uma classe com somente uma responsabilidade.

Por que estou lembrando disso? Por que o TDD nos “força” a termos classes seguindo esta regra, pois facilita os Testes. Não podemos refatorar um trecho de código e quebrar vários Testes. Assim, este princípio acaba sendo utilizado, mesmo que você não perceba.

Pronto! Como acabamos a refatoração, o próximo passo é o próximo Teste!

Sendo chato, parte II
No último passo aplicamos a Refatoração, que é a melhoria do código. Isto se faz necessário(leia-se bom) sim em relação às boas práticas já conhecidas, porém com TDD isso se torna obrigatório!

Por que? Simples! Para escrevermos um Teste, escrevemos uma funcionalidade, mas esta funcionalidade não pode quebrar outro Teste. Ao quebrar outro Teste, temos que fazer um pequeno esforço para que o nosso novo código esteja menos acoplado ao código restante.

Viu o que aconteceu? Trocamos a forma de desenvolvimento. Em vez de projetarmos a nossa aplicação e tentarmos escrever um código (levando horas) pensando nas mudanças no futuro, já pensando nos Patterns, regras e etc, escrevemos um código de Teste que guiou a simplicidade do nosso código, que em seguida refatoramos para deixá-lo menos acoplado e com uma maior coesão, fazendo com que este código seja facilmente modificado no futuro, seja para correção de problemas ou para novas funcionalidades.

Mundanças seguras no código
Muitos desenvolvedores ainda escrevem código pensando nas modificações no futuro que este código poderia ter e acaba escrevendo um código com Factory, Singleton,  Template Method, Bridge, Strategy e todos os amigos do GoF. Este pensamento, apesar de parecer seguro, contraria os princípios da Metodologia Ágil.

Claro que o software sempre sofrerá mudanças e a nossa preocupação de hoje é:
- Prever/Escrever um código/design para modificar no futuro quando precisarmos
Mas deveria ser
- Escrever um código simples e claro, que seja fácil modificar e seguro

Kent Beck, no seu livro também comenta sobre perdermos muito tempo imaginando um Design que seja perfeito para aplicação e acabamos escrevendo um código que na maioria das vezes não era necessário.
Com TDD realmente abandonamos este pensamento, justamente por queremos que o Teste passe logo, ou seja, escrevemos o nosso código da forma mais simples possível.

Como conseguimos um código simples? -> Fazendo um Teste passar
Como conseguimos um código claro?      -> Refatorando o código após ele passar
Como conseguimos um código seguro?   -> Com Testes

Documentação para o limbo?
Não. Aquela documentação no papel, em uma wiki, em um doc, etc é desatualizada pois é muito custoso atualizá-la a cada Refatoração/Mudança de código.
A melhor documentação e mais atualizada possível é a Suíte de Testes pois ela mostra de forma simples como está funcionando o sistema naquele exato momento. Se você percorrer os testes você entenderá o que o sistema realiza.

Finalizando
Neste artigo comentamos de forma simples sobre os pontos do ciclo do desenvolvimento com TDD e também reforçamos a idéia  e os motivos para utilizá-lo.

Agora temos o conceito fixado na cabeça e adoramos TDD! No próximo artigo escreveremos algumas funcionalidades de um sistema com TDD, utilizando a Java com o JUnit. Logo mais utilizaremos também o JMock ou Mockito que também facilitará muito os nossos Testes!

Abraços Pessoal!!!

¹Suite de Testes: Basicamente é um grupo de testes do sistema. São os testes de certo módulo agrupados, onde podem ser rodados em conjunto ou separadamente.