DBUnit com HSQLDB + Hibernate + maven

Olá pessoal!

No post de hoje vamos ver como executar nossos unit tests usando o DBunit com HSQLDB em memória, tendo o Hibernate como framework de persistencia e usando o maven. por que isso tudo? Eu passei por uns problemas chatos de configuração que normalmente não temos quando fazemos testes de cada um desses recursos separados, mas, quando tive que colocar tudo na mesma panela, surgiram uns problemas mais chatos para nós, desenvolvedores, estou falando daquelas exceções de não achar o arquivo, exceções genéricas dos frameworks, que nos faz ficar horas e horas googlando, etc.

lets go..

O que vou considerar?

Que você já conhece Hibernate e conhece o DBunit, porém agora pretende rodar seus testes em um projeto do tipo maven e que você tem dois arquivos hibernate.cfg.xml, um para os testes e outro para a aplicação em si.

O problema

Tudo começou quando, ao executar meus testes, simplesmente recebi aquela velha mensagem: cannot open JDBC Connection. Eu disse “como assim? O hibernate.cfg.xml está lá”. Daí comecei a investigar. Um ponto eu já sabia e publiquei aqui nesse troubleshooting: o maven procura o hibernate.cfg.xml em src/main/resources. E para os testes? Ele procura em src/test/resources. Até parece lógico, mas errei aqui e não coloquei meu arquivo de hibernate.cfg.xml de teste nesse local. Porém, veio outro problema: eu tinha renomeado meu arquivo hibernate.cfg.xml para hibernateTest.cfg.xml. Por que? Simplesmente queria ter essa diferença. E deixava assim a configuração nos meus testes:

 protected IDatabaseConnection getConnection() throws Exception {

conn = new DatabaseConnection(new Configuration().configure(“hibernateTest.cfg.xml”)

.buildSettings().getConnectionProvider().getConnection());

return conn;

}

Simplesmente recebia:


 

Dai o que fiz?

Mudei o arquivo para hibernate.cfg.xml e rodei a aplicação e o resultado:

 

Isso me custou umas 3hrs do meu dia. Infelizmente não fui pesquisar porque com o nome diferente do hibernate o maven não encontrava o arquivo, somente com o nome default.

O arquivo do DBunitTest é o mesmo que vimos nos outros post da série, a única diferença é que temos um projeto do tipo “simple maven project”.

Hibernate.cfg.xml para o HSQLDB

<session-factory>

<property name=”hibernate.connection.driver_class”>org.hsqldb.jdbcDriver</property>

<property name=”hibernate.connection.url”>jdbc:hsqldb:mem:db</property>

<property name=”hibernate.connection.username”>sa</property>

<property name=”hibernate.dialect”>org.hibernate.dialect.HSQLDialect</property>

<property name=”hibernate.show_sql”>true</property>

<property name=”hibernate.hbm2ddl.auto”>create-drop</property>

<mapping class=”com.camilolopes.qa.model.dao.bean.Account”/>

</session-factory>

 

Configuração do pom.xml Adicione as dependencias abaixo:

<dependency>

<groupId>hsqldb</groupId>

<artifactId>hsqldb</artifactId>

<version>1.8.0.10</version>

</dependency>

<dependency>

<groupId>javassist</groupId>

<artifactId>javassist</artifactId>

<version>3.12.1.GA</version>

<type>jar</type>

<scope>compile</scope>

</dependency>

<dependency>

<groupId>org.hibernate</groupId>

<artifactId>hibernate-core</artifactId>

<version>3.6.10.Final</version>

<type>jar</type>

<scope>compile</scope>

</dependency>

<dependency>

<groupId>org.dbunit</groupId>

<artifactId>dbunit</artifactId>

<version>2.4.8</version>

<type>jar</type>

<scope>compile</scope>

</dependency>

 

Crie um bean e um teste para persistir o objeto:

Bean

@Entity

@Table(name=”account”)

public class Account {

@Id

@GeneratedValue

@Column(name=”ID”)

private Long id;

@Column(length=20,name=”TYPE”)

private String type;

}

Test

A classe de test deverá estar assim, e omitir o que não mudou do outro arquivo, como a conexão e o load do .xml.

public DBUnitTest() {

try {

session = getSessionFactory().openSession();

getDataSet();

} catch (Exception e) {

e.getMessage();

}

}

public static SessionFactory getSessionFactory() {

sessionFactory = new Configuration().configure().buildSessionFactory();

return sessionFactory;

}

@Test

public void testSave(){

session.beginTransaction();

Account account = new Account();

account.setType(“USER”);

session.save(account);

}

Enfim, é isso ai. Caso precise rodar seus unit tests com maven + hibernate + hsqldb, sem ter dor de cabeça com arquivo de configuração, essa foi a solução que encontrei.

Abracos, see ya!!

Testes com DBUnit & HSQLDB

Olá Pessoal, 

Hoje veremos como deixar nossos testes com DBUnit usando o HSQLDB. O motivo que queremos rodar o banco em memoria, ou seja, evitarmos de termos que ter o banco rodando para executar os testes, o mesmo será iniciado somente quando os testes forem executado. Como você pode observar no último post, sempre temos que ter o MySql rodando para que as coisas funcionem e  ter essa dependência no dia-dia enquano estamos desenvolvendo é ruim, pois vamos exigir que cada desenvolvedor tenha que ter o MySql instalado na maquina etc. Não queremos isso. Queremos que ele faça o checkout do código e possa rodar. 

Lets go…

Starting…

Como já falado no post  anterior vimos como automatizar nossos testes usando DBUnit + Mysql, porém o que vimos de ruim é o fato de ter sempre o serviço do MySql rodando. E se quisermos rodar isso em memoria, como fazer? O HSQLDB nos dá uma mãozinha para rodar nossos testes com o HSQLDB, é muito simples, basta alterarmos o hibernate.cfg.xml e ter o .jar do HSQLDB adicionado ao projeto.

Vou considerar que você tem o projeto anterior, mas caso não tenha, siga os passos do primeiro post e mude apenas o arquivo do hibernate.cfg.xml.

1. O primeiro passo é criar o arquivo hibernate.cfg.xml com as configurações do banco onde os testes serão executados.

<hibernate-configuration>

<session-factory>

<property name=“hibernate.connection.driver_class”>org.hsqldb.jdbcDriver</property>

<property name=“hibernate.connection.url”>jdbc:hsqldb:mem:db</property>

<property name=“hibernate.connection.username”>sa</property>

<property name=“hibernate.dialect”>org.hibernate.dialect.HSQLDialect</property>

<property name=“hibernate.show_sql”>true</property>

</session-factory>

</hibernate-configuration>

Pronto, feito isso basta rodar os testes novamente e done. O resultado é Green .  Simples, não? Assim tiramos a dependência do MySql.

Vou ficando por aqui… Essa foi fácil.

Abraços, see ya!!

Automatizando seus testes com DBUnit + MySQL

olá Pessoal, 

No post de hoje vamos ver como rodar unit tests usando o DBUnit com MySql.  O DBUnit é uma API para fazermos testes unitários usando um banco de dados.

Starting…

Para rodar os testes automatizados é muito simples: precisamos apenas escolher o banco que vamos rodar e de um (ou mais) arquivos .xml que vai representar os dados a serem testados.

***Crie um projeto Java.

1. Primeiro passo é criar o arquivo hibernate.cfg.xml com as configurações do banco onde os testes serão executados.

<hibernate-configuration>

 <session-factory >

  <property name=“hibernate.connection.driver_class”>org.gjt.mm.mysql.Driver</property>

  <property name=“hibernate.connection.password”>camilo</property>

  <property name=“hibernate.connection.url”>jdbc:mysql://localhost/test</property>

  <property name=“hibernate.connection.username”>root</property>

  <property name=“hibernate.dialect”>org.hibernate.dialect.MySQL5InnoDBDialect</property>

  <property name=“hibernate.show_sql”>true</property>

 </session-factory>

</hibernate-configuration>

2. Criar uma classe que obtém a SessionFactory com  base nas informações do arquivo hibernate.cfg.xml

 

public class HibernateUtil {

       private static SessionFactory sessionFactory;

       public static SessionFactory getSessionFactory() {

             sessionFactorynew Configuration().configure().buildSessionFactory();

             return sessionFactory;

       }     

}

3. Criaremos um arquivo .xml (chame como quiser, chamarei de datalogin.xml. Ele deve tá no src do seu projeto)que representa a tabela do banco, conforme abaixo:

 

<?xml version=“1.0” encoding=“UTF-8”?>

<dataset>

<login id=“1” login=“camilo” senha=“124”/>

<login id=“2” login=“neto” senha=“234”/>

</dataset>

 

4. Agora vamos criar a nossa classe de Teste. Para questão apenas de explicação, subscrevi alguns métodos da classe do DBunit para explicar como as coisas funcionam, porém em outros é necessário implementarmos para que o DBunit saiba onde ele terá que conectar e pegar os dados:

public class DBunitTest extends DatabaseTestCase{

       private Session session;

       private IDatabaseConnection conn;

       private IDataSet dataSet;

       private FileInputStream loadFile;

       public DBunitTest() {

             try {

                    session = HibernateUtil.getSessionFactory().openSession();               

             } catch (Exception e) {

             e.getMessage();

             }

       }

       @Before

       public void setUp() throws Exception { 

//           a cada execução dos testes ele limpa e insere

             getSetUpOperation();      

       }

//     limpa tudo que tem nas tabelas e faz um insert

       @Override

       protected DatabaseOperation getSetUpOperation() throws Exception {

             return DatabaseOperation.CLEAN_INSERT;

       }

/* aqui que o pulo do gato

 * (non-Javadoc)

 * @see org.dbunit.DatabaseTestCase#getConnection()

 * fornecemos a forma de conexão ao banco, estou usando o Hibernate

 * não usar o método session.getConnection() ele está deprecated e vai sumir na versão 4.0

 */

       @Override

       protected IDatabaseConnection getConnection() throws Exception {

             conn = new DatabaseConnection(new Configuration().configure().buildSettings().getConnectionProvider().getConnection());

             return conn;

       }

/*

 * (non-Javadoc)

 * @see org.dbunit.DatabaseTestCase#getDataSet()

 *

 * fazer o load dos dados que serão testados

 */

       @Override

       protected IDataSet getDataSet() throws Exception {

             loadFile = new FileInputStream(“src/datalogin.xml”);

             dataSet =  new  FlatXmlDataSet(loadFile);

             return dataSet;

       }

}

Para facilitar o entendimento, a explicação está nos comentários in line, assim você lê, olha e aprende direto no código.

Testando

Agora vamos testar. Para isso, certifique-se que o MySql foi inicializado e adicione no final da classe DBunitTest o seguinte teste:

@Test

       public void testCheckLoginDataLoaded() throws Exception{

             assertNotNull(getDataSet());

             int rowCount = getDataSet().getTable(“login”).getRowCount();

             assertTrue(rowCount!=0);   }

 O teste é muito simples, apenas quero garantir que estamos conectados ao BD com os dados do dataset (observe que temos assert que verifica isso).  O resultado será:

Simples, não? Agora é apenas adicionar os cenários de testes no seu dataset, fazer as devidas implementações do DAO e chamar através dos seus testes.

Vou ficando por aqui.

See ya!! 

Lançamento livro: TDD na Prática

Olá Pessoal!
É com muita felicidade que venho compartilhar com vocês mais esse “filho”. Eu não sei nem por onde começar de fato. Mas que tal pelo inicio?
Bom, a seguir falo um pouco da história dele (como todo livro meu sempre tem uma história real por trás), porque escrevi, quem pode ler,  sorteio etc Vou buscar ser bem breve..
Lets go…
Agradecimentos
Fazer esta parte aqui nunca é fácil, pois são várias pessoas que contribuem para uma obra como esta: amigos, colegas de trabalho, familiares, amigo virtual, etc. E lembrar de cada um não é uma tarefa fácil. Sendo assim, estarei destacando aqueles que vieram em memória no momento que escrevo este trecho.  Aqueles que contribuíram e acabei esquecendo, peço que me perdoem.
Primeiro, não poderia esquecer o meu colega de trabalho Gustavo Knuppe. Apesar dele não saber que estava escrevendo este livro, foi responsável por muitas mudanças que fiz na forma de abordar o assunto de TDD, principalmente em um artigo, no qual Knuppe foi o revisor, e nesse processo sugiram várias e boas sugestões no artigo produzido que aproveitei para utilizar neste projeto.
Um amigo que não poderia deixar de fora é o Alberto Leal. Eu diria que meu contato com mundo Agile começou devido a uma apresentação sobre refactoring que o Leal fez em alguns minutos via MSN e depois desse dia fui me envolvendo mais e mais com a técnica e quando conheci TDD e liguei o passado com o presente vi que ter conhecido refactoring com o Alberto fez uma diferença grande. Obrigado meu amigo!
À minha namorada Ellis Ribeiro, que teve a paciência e dedicação em revisar a parte ortográfica e dar sugestões de melhoria na estrutura do livro 🙂
Como tudo começou… (Era uma vez….)
Bem, primeiro nunca imaginei que um dia eu escreveria um livro sobre TDD, independente de que foco este teria. Até porque eu não sabia nada do assunto até inicio de 2010, apenas ouvia. Tinha tentado usar algumas vezes antes e fracassei em todas elas. Nunca entendia de fato como fazer os unit tests, muito menos escreve-los primeiro, mas fiquei com aquilo na cabeça. Todos (Kent Beck, Martin Fowler, Guilherme Silveira, etc) falam e conseguem, daí eu me perguntava: “o que eu estou fazendo de errado? Não vou desistir de entender direito.”  Dai passou o tempo, tive que voltar a estudar devido a um projeto que precisei trabalhar em 2010 e tinha que escrever unit tests para as coisas darem certo e então fui estudando, começei a ler e pesquisar com mais detalhe. Lembro que o primeiro post que li sobre o assunto foi do Guilherme Chapiewski. Fui navegando para outros blogs, tentando entender a mecânica e praticar. Comecei a pegar o ritmo, mas confesso que naquele momento não sabia que eu fazia TDD na veia, era complicado, pra mim era código com um framework que eu testava o que escrevi. Mas cada vez que programava gostava do resultado, ficava viciado, daí decidi me aprofundar mais no assunto, e fui buscar referências “for dummy”, tanto em português quanto em inglês. Achei? Não, pois identifiquei os seguintes problemas nas obras publicadas sobre o assunto na época:
1. Era necessário ter uma certa experiência (nem que fosse muuuito básica) com a mecânica de unit test;
2. Os livros eram longos e poucos práticos para iniciantes, com exemplos esquisitos que ao término da leitura sentia falta de algo mais concreto para praticar e dizer: ‘entendi de fato com a mão na massa’. Enfim, faltava uma direção melhor para iniciantes.
E foi quando despertou de sair anotando tudo que ia aprendendo, tanto aquilo que deu certo quanto o que deu errado também. Meses depois (no final de 2010), por “ironia” do destino caiu no meu caminho o meu primeiro projeto, o qual usariamos TDD. Mesmo sendo pequeno ajudou muito, digo que foi onde tudo começou de fato, com erros e acertos, mas foi gratificante o resultado. Dai fui para um outro mais arrojado, de 1 ano, e TDD foi a base para podermos entregar o código com qualidade, menos bug, menor custo de manutenção e respeitando os prazos. Tudo isso me fez refletir. Um dia parei e olhei para tras e perguntei: “O que aprendi até hoje? Que tal criar um livro sobre o assunto? Aliás, usar minhas anotações, experiência adquirida, para ajudar quem está querendo entrar nesse mundo?” Observei nos fóruns e comunidades Java que muitos tinham vontade de aprender TDD, outros tinham tentado e fracassado, alguns nem sabiam por onde começar.
 Enfim, todos os problemas que passei eram bem recorrente para todo iniciante. E foi aí que nasceu o meu livro “TDD na Prática”. Essa é a história dele.
Quem pode ler?
Essa é uma pergunta muito comum: “será que devo comprar?” Eu digo sempre o seguinte: compre o livro se você:
1. Conhece bem o básico do Java e Orientação a objetos. Olha o que eu estou falando, conhece bem JAVA e não JEE. Iniciantes ainda fazem confusão com as siglas do Java (não deveria, pois a primeira lição é saber as diferenças);
2. Sabe o que é unit tests ou tem ideia de para que serve;
3. Sabe a diferença entre unit test x Junit;
4. Quer de fato aprender TDD e saber que, no inicio, será um caminho duro, sofrido, pois não é só sentar na máquina e sair codificando. É uma forma diferente de pensar, codificar, resolver problemas, que no resultado final isso é transparente para quem olha sua aplicação e diz: “Essa eu digo 100% que foi feito com TDD, mas essa não”. A olho nú não é possível dizer isso.
5. Gosta de desafios e quebrar a cabeça;
Se você se encaixa nos pontos acima, pode adquirir um exemplar, caso contrário, eu diria que não compre :).
Como o livro está estruturado?
Bem, para quem conhece meus livros sabe que sou bem informal na escrita e gosto de dar a sensação ao leitor que estamos mais batendo um papo que lendo um livro em si. Com esse não será diferente, pois é meu jeito natural de escrever. Mas o que eu coloquei no livro?
Bom, quando começei a escrever a primeira pessoa que eu pude me espelhar era eu mesmo, aquele cara que não sabia:
  • – nada de TDD na prática, só ouvia falar;
  • – conceitos de Agile, muito abstrato ou quase nenhum;
  • – tanta sigla, termos TDD, Mocks, Mockito, Junit, refactoring que na prática, juntando tudo no “liquificador”, nunca sabia se o resultado final era de fato o esperado;
  • – e um cara que não sabia programar usando unit test; Alias, mal entendia uma classe que tinha métodos com as anotações @Test. Me perguntava “pra que realmente isso serve? como pode agregar valor na aplicação?” Só ouvia as pessoas falarem: “É bom”. “Funciona”. “Usa isso que vai ser show”, “Seus problemas acabaram, use unit test”. Mas no fundo não entendia como, e tive que aprender isso sozinho.
Então o livro segue uma ordem que, a depender em que nível você está, pode ir lendo sequencialmente. Eu diria que se é bem iniciante mesmo, vá na ordem sequencial, mas se você já sabe mocks, usar o JUnit, etc, pode pular alguns e ir para o qual lhe interessa de imediato.
Coloquei exercícios para serem feitos com o objetivo de forçar o leitor a exercitar o que aprendeu sobre TDD de formas diferentes. Vamos começando em um nível com a minha ajuda, mas depois deixo você ir sozinho, tomando suas decisões de quais testes escrever. Isso ajuda a ganhar confiança naquilo que está fazendo, o que no inicio com TDD todos se sentem desconfortável, inseguros e se perguntando: “será que estou fazendo a coisa certa? É isso mesmo?”. Enfim, espere exercícios um pouco diferentes do que você está acostumado a fazer no dia-dia. Também compartilho com o leitor como eu faço TDD e a gente vai vendo o que da certo e não da. Em alguns exercícios há respostas, para depois o leitor comparar e ver como resolvi. Não quer dizer que o seu tem que ser igual ao meu, cada um resolve de uma forma. O objetivo é que você tenha feito realizando os testes primeiro. Mas há outros que não temos a resposta. Fiz esses para que você possa olhar para o problema e garantir que atendeu ao requisito, ou seja, resolveu de fato usando TDD sem ter outra solução para preparar. Isso ajuda a ter mais confiança no que você entrega, já que todo “TDDista” sempre vai ouvir a seguinte frase: “Isso não funciona”, “Isso é coisa de nerd”. “Só funciona no mundo do Kent Beck e Martin Fowler”. Mas acostume-se com esses e outros comentários, faz parte do dia a dia, e o melhor de tudo: não se irrite. Há um capítulo que explico o Junit, Mocks, refactoring, falo rapidamente sobre Agile e Scrum.
Onde adquirir um exemplar?
Acredito que, dentro de uma semana no máximo, o livro estará disponível nas melhores livrarias, como: Saraiva, Cultura, Fnac, etc. E nas lojas virtuais: livrosdeprogramacao.com, submarino.com.br, americanas.com.br  etc.
No site da editora você pode comprar: www.lcm.com.br.
Formato do livro:
O livro será disponibilizado no formato impresso (R$ 36,80) e e-book(R$ 27,80). A versão ebook só será vendida pelo site da editora.
SlideShare
Disponibilizei no slideshare alguns capítulos do livro.
Sorteio
Você tem até 02/12/2012 para realizar o seu cadastro. No dia 03/12/2012 divulgarei o resultado.
Regras:
  • – Não é permitido realizar 2 cadastros. E-mails duplicados e a pessoa não estará mais participando do sorteio. Então façam apenas 1 cadastro por e-mail. Lembrando que deve ser um e-mail válido, pois o contato para confirmação dos dados será feito pelo e-mail cadastrado, e o ganhador tem até 48hrs para responder, a partir da data de recebimento. Caso contrário, um novo sorteio será feito;
  • – O livro será enviado para o endereço informado no cadastro. Então coloque o endereço completo + ponto de referência.
Atualização: 
O ganhador poderá escolher se deseja a versão impressa ou e-book.
Resultado
O ganhador foi: Rafael Oliveira
note: Um e-mail foi enviado para o ganhador o mesmo tem até 48hrs para confirmar o recebimento e dados de entrega. Caso não seja respondido em 48hrs a partir da data de envio, um novo sorteio será realizado. 
 Bom, vou ficando por aqui.
Demorou, mas chegou. 🙂
See ya!!

TDD não é receita de bolo

olá Pessoal,

O post de hj é bem curto, mas uma reflexão sobre TDD. O post nasceu após ter passado em alguns projetos, onde todos falaram que TDD era uma pedra no caminho e que não consigam medir se a técnica ajudou ou não a entrega do produto. Só quando eu ouvir essa frase eu fiquei já “assustado”. Como assim medir TDD? A seguir veremos que TDD não é uma receita de bolo que seguindo os passos 1-x estamos fazendo TDD. Não é bem por ai.  

Muitos desenvolvedores, gestores, arquitetos  acreditam fortemente que TDD é apenas criar unit test ou somente fazer os testes primeiro. Isso não é verdade. Primeio que TDD é abstract e não nada dizendo como TDD é. Apenas existe um ciclo de vida  com as fases que devemos exercitar ao  querer dizer que estamos fazer TDD. Mas, ,mesmo assim não há um passo que de 1-10, se você corretamente  terá 100% de certeza que fez TDD. Por isso que falo TDD não é receita de bolo. E aqui vai algumas justificativas:

  1. Em uma receita de bolo há passos de como preparar, mas TDD não diz como fazer seus testes;
  2. Na preparação de um bolo, há quantidade certa dos ingredientes, mas TDD não diz a quantidade certa  de unit test;
  3. O fato de eu ter misturado os ingredientes  e seguido os passos  não quer dizer que terei um bolo no final, o fato de seguir o ciclo de vida de TDD não quer dizer que fiz TDD.

Eu vejo muito por ai, pessoas associando TDD apenas aos unit tests, isso não é verdade. Também já passei em projeto onde as pessoas, entendiam completamente errado o que TDD é na verdade. E associam atrasos de entregas a técnica. Eu costumo dizer: “se você diz que precisa de mais tempo para entregar por causa de TDD, vc tá fazendo algo de errado”. E isso é fato, não há relação alguma que  precisamos de mais tempo para entrega por cause de TDD, o problema está se o desenvolvedor realmente entendeu como fazer seus testes. Vejo muito que estão acostumado a programar orientado seguindo passos, ou a uma ferramenta, TDD força o desenvolvedor a pensar, entender , refletir antes de sair programado. Quem faz TDD quando vai programar já sabe o que vai escrever e não sai escrevendo qualquer coisa. Mas, isso não são para todos. Pois, exige tempo e paciência. E o mais fácil é dizer, TDD não funciona. Eu pergunto como vai funcionar se TDD é abstrato? TDD não é framework, um software que você coloca na máquina e no final tá funcionando.

Vou ficando por aqui.

Abraços,