Série Spring: CRUD Spring 3 + Hibernate + Unit Tests

Olá Pessoal,

No post de hoje veremos como fazer um simples CRUD usando o Spring, integrando com Hibernate e testando via unit tests com JUNIT4. No último posts vimos apenas uma integração com o Hibernate e também um CRUD usando HibernateTemplate, esse aqui  veremos que na versão 3 do Spring não precisamos mais do HiberanteTemplate e vamos testar nosso código com unit test.

Lets go…

Starting…

Primeiro passo é que  estarei assumindo que você já tem .jars necessário  para o ambiente. Já que esse não é o primeiro post da série, caso contrário terá que baixar os .jars para: driver Mysql 5, Hibernate 3.6, AOP, AspectJ, Spring 3.x.

Antes de começarmos a desenvolver, vamos primeiro estruturar nosso projeto e packages conforme a imagem a seguir:

springrentcarproject

Nosso CRUD será o cadastro  de veículos  que serão alugados. Claro que há muito mais regras de negócios do que a que veremos no exemplo a seguir, porém o nosso objetivo é explorar o framework Spring e não tratar todas as regras de negócio em um post.

  1. Crie a estrutura conforme a imagem acima
  2. Crie o arquivo de configuração de Spring, o qual chamei de springconfiguration.xml, e coloque dentro do package config.
  3.    Agora vamos colocar a carne no nosso XML

Cabeçalho fica assim:

<beans xmlns=“http://www.springframework.org/schema/beans”

xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”

xmlns:context=“http://www.springframework.org/schema/context”

xmlns:tx=“http://www.springframework.org/schema/tx”

xmlns:aop=“http://www.springframework.org/schema/aop”

xsi:schemaLocation=“http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-3.0.xsd

http://www.springframework.org/schema/tx

http://www.springframework.org/schema/tx/spring-tx-3.0.xsd

http://www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring-aop-3.2.xsd”>

 

Estarei comentando mais na frente ou in line apenas o que  ainda não foi abordado nos posts anteriores.

O cara que busca os beans: 

<context:component-scan base-package=“*”/>

 Colocando translation

<!– esse cara faz as traduções das exception checked para as unchecked do Spring –>

<bean class=“org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor”/>

Data source

<!– pelo nome diz, data source para conexão com o DB –>

<bean id=“dataSource” class=“org.springframework.jdbc.datasource.DriverManagerDataSource”>

<property name=“driverClassName” value=“com.mysql.jdbc.Driver”/>

<property name=“url” value=“jdbc:mysql://localhost/test”/>

<property name=“username” value=“root”/>

<property name=“password” value=“camilo2593”/>

</bean>

 

Configurando a SessionFactory

<!– Aqui estamos definido como será a parte de persistêcia, e dizemos que faremos via annotation –>

<bean id=“sessionFactory” class=“org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean”>

<!– informando a quem estaremos conectado –>

<property name=“dataSource” ref=“dataSource”/>

<!– dizendo onde estão as classes dominio, ele saberá devido anotação @Entity  –>

<property name=“packagesToScan” value=“br.com.camilolopes.rentcar.domain.bean”/>

<!– configurando coisas especificas do Hibernate –>

<property name=“hibernateProperties”>

<props>

<prop key=“hibernate.dialect”>org.hibernate.dialect.MySQL5InnoDBDialect</prop>

<prop key=“hibernate.hbm2ddl.auto”>update</prop>

</props>

</property>

</bean>

 

Definindo Transaction

 <!– definindo quem vai gerenciar as transaction, ou seja, será o Hibernate –>

<bean id=“transactionManager” class=“org.springframework.orm.hibernate3.HibernateTransactionManager”>

<property name=“sessionFactory” ref=“sessionFactory”/>

</bean>

</beans>

Há duas formas de declararmos as transaction no Spring por XML ou Annotation.  Veremos as duas formas, no nosso caso de usarmos o XML faremos com AOP e você entenderá o  motivo:

Via XML

<!– todo medoto que começa com add é required uma transaction –>

<tx:advice id=“txAdvice”>

<tx:attributes>

<tx:method name=“add*” propagation=“REQUIRED”/>

<tx:method name=“update*” propagation=“REQUIRED”/>

<tx:method name=“*” propagation=“SUPPORTS” read-only=“true”/>

</tx:attributes>

</tx:advice>

<!– toda classe que extends a interface terá uma referência para o advisor –>

<aop:config>

<aop:advisor pointcut = “execution(* *..RentCar.*(..)))” advice-ref=“txAdvice”/>

</aop:config>

 

Em alguns contexto dessa forma é bem mais prático que usar Annotations.

 

Via annotation

Remove todo o código XML acima e apenas adiciona a seguinte linha:

<tx:annotation-driven/>

 

Claro que teremos que anotar nas classes/métodos como @Transaction e informar como esse deve se comportar , seguindo o exemplo do XML acima seria algo  assim:

@Transactional(readOnly=true,propagation=Propagation.SUPPORTS)

public class myClass{  }

 

Normalmente você colocaria isso na camada de serviço.Mas, se você está brincando  e não tem uma camada de serviço, pode colocar direto no DAO.

E o método que faria uma das operações de banco ficaria assim:

@Transactional(isolation=Isolation.DEFAULT,propagation=Propagation.REQUIRED)

      public void save(Car car) {

            getCurrentSession().save(car);}

 

No nosso exemplo vamos não vamos usar Annotations e exploraremos o benefício de usar a versão do XML conforme acima, se vc deixar a tag para annotation no arquivo de configuração o Spring não vai se importar com isso.

Desenvolvimento

Após toda essa configuração, vamos agora desenvolver nossas classes .java. Começando pela classe de domínio:

@Entity

@Table(name=”CARS”)

public class Car implements Serializable{

private static final long serialVersionUID = -2896368465389020843L;

      @Id

      @GeneratedValue

      private Long id;

      private String manufacter;

      private String description;

      private BigDecimal marketValue;

                //getters/setters omitidos

Basicamente isso .

Interface DAO

public interface RentCarDAO {

      void save(Car car);

      List<Car> findAll();

      List<Car> findAllByDescription(String description);

      void update(Car car);

      void delete();

}

Implementação da Interface:

@Repository

public class RentCarDAOImpl implements RentCarDAO {

      @Autowired

      private SessionFactory sessionFactory;

      public Session getCurrentSession(){

            return sessionFactory.getCurrentSession();

      }

      @Override

      public void save(Car car) {

            getCurrentSession().save(car);

      }

      public void setSessionFactory(SessionFactory sessionFactory) {

            this.sessionFactory = sessionFactory;

      }

      @Override

      public List<Car> findAll() {

            return getCurrentSession().createCriteria(Car.class).list();

      }

      @Override

public List<Car> findAllByDescription(String description) {

Criteria createCriteria = getCurrentSession().createCriteria(Car.class);

createCriteria.add(Restrictions.ilike(“description”, description));

            return (List<Car>) createCriteria.list();

      }

      @Override

      public void update(Car car) {

            getCurrentSession().update(car);

      }

      @Override

      public void delete() {

Query query = getCurrentSession().createQuery(“delete from Car where id >0”);

            query.executeUpdate();

      }

Interface de Serviço

@Service

public interface RentCar {

      void addNewCar(Car car);

      List<Car> findAll();

      List<Car> findCarByDescription(String description);

      void updateCar(Car car);

      void delete();

}

Classe que implementa o Serviço

@Service

public class RentCarServiceImpl implements RentCar {

      @Autowired

      private RentCarDAO rentCarDAO;

      @Override

      public void addNewCar(Car car) {

            rentCarDAO.save(car);

      }

      public void setRentCarDAO(RentCarDAO rentCarDAO) {

            this.rentCarDAO = rentCarDAO;

      }

      @Override

      public List<Car> findAll() {           

            return rentCarDAO.findAll();

      }

      @Override

      public List<Car>findCarByDescription(String description) {

           return (List<Car>) rentCarDAO.findAllByDescription(description);

      }

      @Override

      public void updateCar(Car car) {

            rentCarDAO.update(car);

      }

      @Override

      public void delete() {

      rentCarDAO.delete();     

      }

}

 

Unit Test

Se não reparou quando criou o projeto, temos um source  apenas  para os unit tests, conforme a imagem a seguir:

springrentcarunittestssource

Agora crie a classe de teste. A seguir mostrarei apenas dois simples testes, você deve criar os demais para validar os cenários, não coloquei todos para não ficar mais longo ainda o post.

@RunWith(SpringJUnit4ClassRunner.class)

@ContextConfiguration(locations={“classpath:config/springconfiguration.xml”})

public class RentCarServicesTest {

      @Autowired

      private RentCar rentCarServicesImpl;

      private Car car;

      @Before

      public void setUp() throws Exception {

            car = new Car();

      }

      @Test

      public void testAddingNewCarWithSuccess(){

            try{

                  car.setDescription(“Civic”);

                  car.setManufacter(“Honda”);

                  car.setMarketValue(new BigDecimal(740000));

                  rentCarServicesImpl.addNewCar(car );

            }catch (Exception e) {

                  Assert.fail(“not expected result”);

            }

      }

      @Test

      public void testListAllCarIsNotEmpty(){

            assertFalse(rentCarServicesImpl.findAll().isEmpty());

      }

 Resultado

Lembre-se que seu BD precisa está rodando

springhibernateunittestresult

 

Ufa! Esse post foi longo heim, mas não tinha outra forma de mostrar tudo se não fosse assim, e olha que busquei resumir ao máximo possível. Enfim, vou ficando por aqui.

GitHub

Acesse o repositório no github com todos os projetos da série Spring:  https://github.com/camilolopes/workspacespring

Espero que tenham gostado do post.

Abraços, see ya!! 

Pré-Lançamento: Livro TDD na Prática

Olá pessoal,

É com muita felicidade que escrevo este post. Realmente só quem é “pai” sabe o que eu estou sentido. Como vocês já podem imaginar está vindo ai mais um filho para se juntar aos seus irmãos “Guia do exame SCJP” e “Guia Prático JEE”. É ele o “TDD na Prática”. O livro está previsto para ser publicado até o final de junho/2012. Ainda não recebi a versão final do livro, mas assim que receber estarei disponibilizando alguns capítulos. A seguir faço uma pequena apresentação sobre o meu filhão.

lets go…

Sumario Tdd na Prática

Sobre o livro

O livro vem com um objetivo simples: “Descomplicar o que parece ser complicado”, em outras palavras O objetivo é ensinar como praticar TDD usando a linguagem de programação Java. Para muitos iniciantes em TDD, no primeiro momento parece que estamos fazendo tudo errado e que escrever os testes antes do código funcional não é nada legal. E que para superar os primeiros obstáculos, só o conhecimento técnico não é suficiente. Quando comecei com TDD passei por vários obstáculos e um deles foi encontrar livros práticos, ou seja, aqueles que eu pudesse colocar a mão na massa de verdade, ter problemas para resolver usando a técnica, etc. Os disponíveis eram bastante teórico, deixando a parte prática sobre minha responsabilidade que, como iniciante, era difícil saber por onde começar. Esses livros foram importantes para entendimento e formação da minha base teórica sobre o assunto, mas eu percebi que uma coisa era eu ter lido e outra era praticar e me ver com o Eclipse aberto e sem saber o que fazer de verdade, ou pior, me perguntar: ‘como resolver um problema usando TDD e não cair na tentação de escrever os testes por último?’. Quem não tem cão caça com gato. Tive que criar meu próprio caminho prático, onde comecei a desenvolver novas aplicações usando a técnica (venci pela persistência), em seguida surgiu  a oportunidade de ir para um projeto novo na empresa que trabalhava e lá tive o espaço para desenvolver usando TDD por quase 2 anos, e nesse meio surgiu a ideia desse livro: “por que não criar um livro prático sobre TDD com base na minha experiência?”. E foi assim que comecei a escrever o livro no final de 2010, tendo como referência o Kent Beck.  

O que você vai encontrar no livro:

  • Desenvolver aplicações Java usando a técnica de TDD;
  • Exercícios Práticos;
  • O uso de objetos mocks com Mockito;
  • Praticar algumas técnicas de Refactoring ;
  • Entender os valores do mundo Agile;
  • Por que TDD?
  • Junit;

E como sempre, dei preferência em usar uma linguagem informal e fazendo o uso bastante da primeira pessoa. O motivo é que durante seus estudos quero que tenha a sensação de estar batendo um papo comigo ao invés de estar lendo algo mais formal.

Meu desafio

Quando eu decidi escrever esse projeto foi porque me sentir desafiado (assim como os outros já publicados). É isso mesmo. Ao olhar o que tinha em mãos (anotações) mais a experiência e sofrimento com o “mundo TDD” e decepções que passei eu disse: “preciso escrever um livro sobre o assunto”. Daí reparei que escrever um livro com um assunto abstrato não seria uma tarefa fácil, uma vez que TDD, refactoring são técnicas que não se aplicam somente à linguagem Java. E daí eu comecei a entender melhor o livro do Kent Beck (TDD by example) e Martin Fowler (o de Refactoring) o quanto eles são “chatos” e sem sabor para quem é bem iniciante. E eu disse: “preciso fazer algo que empolgue o iniciante, ou seja, algo com sabor, mas que eu não venha perder o eixo principal da técnica”. E daí passei dias pensando, escrevendo, apagando, anotando, dormindo sem respostas e fui vendo como vencer esse desafio de ensinar TDD sem ferir os conceitos da técnica. Isso era o que me tirava o sossego todos os dias e não sei se consegui atingir. Acredito que sim, mas só terei a certeza quando você me escrever dizendo o que achou J. (aguardem até o lançamento…)

Quem pode ler?

O publico alvo são estudantes da tecnologia Java que querem aprender usar TDD desde o principio e tem simpatia com o mundo Agile.Se você ainda está dando os primeiros passos com Java e gosta de ser desafiado, este livro é para você. Indiretamente o livro acaba revisando alguns conceitos básicos do Java nada fora do normal, porém agora o desafio é você fazer as coisas mais simples escrevendo seu teste primeiro. Como eu já passei por isso, sei o quanto difícil é escrever os testes primeiro antes do código funcional e quando eu falo mais simples, não necessariamente é mais fácil.  Se você está bem no inicio do Java, ainda dando “Hello World”, eu diria que o livro não vai ajudar muito nos seus estudos com Java, talvez atrapalhe. A minha sugestão é: aprenda primeiro os fundamentos da linguagem e Orientação à Objetos e depois retorne à todo vapor para ler o livro. Enquanto isso coloque na prateleira e não compre o exemplar.

Pensei em escrever este livro quando, ao iniciar meus estudos com Java, não encontrei um material do qual pudesse desde “pequeno” ir sendo educado com boas práticas, e fui aprendendo no dia-dia, além dos sofrimentos que tive até adquirir uma nova cultura. Se você é aquele iniciante que está a fim de colocar em prática toda essência do Java e ao mesmo tempo ir entendendo o que só ouve falar de TDD, Refactoring, JUnit, este livro é para você.

Eu particularmente diria que este é um tipo de livro que gostaria de ler depois de ter lido Head First Java da Kathy Sierra.

Agradecimentos

Fazer essa parte aqui nunca é fácil, pois são várias pessoas que contribuem para uma obra como essa: amigos, colegas de trabalho, familiares, “amigo virtual” etc. E lembrar todos 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 perdoem.

Não poderia esquecer o meu colega de trabalho Gustavo Knuppe, apesar dele não saber que estava escrevendo este livro, foi responsável em muitas mudanças que fiz na forma de abordar o assunto de TDD.Principalmente em um artigo sobre TDD, o qual Knuppe foi o revisor, e nesse processo, sugiram várias e boas sugestões no artigo produzido e 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 e grande. Obrigado meu amigo!

Outra pessoa é meu amigo Edson Gonçalves, sempre digo que se me tornei um escritor é porque fui “batizado” por esse grande escritor e amigo, o qual já temos um laço de amizade verdadeira por mais de quatro anos. Dedicar este livro para um grande amigo como você é o mínimo que posso fazer. Nos momentos mais difíceis você sempre estava ali comigo me dando força. Abraços e tudo de bom para você meu grande amigo.

Formatos

  • Será vendido no formato impresso e e-book.

Enfim, pessoal essa foi a pequena apresentação do meu próximo livro. Espero que vocês gostem e curtam. Quem quiser divulgar nas comunidades eu não me importo 🙂

Abraços, qualquer dúvida só mandar.

See ya!!!

Criando Mocks com Mockito

olá Pessoal,

No post de hoje vamos ver como usar o API Mockito para criação de objetos mocks. No ultimo post vimos o que são mocks, mas eu já tinha falado rapidamente do Mockito. Usarei o mesmo exemplo visto no post passado, porém agora teremos mocks in action.

Lets go…

Usando JUnit com o Mockito

Para não ter que repetir o código anterior, neste post adicionei apenas a classe que tem o unit test. Então, vou considerar que você viu o nosso post sobre Mocks.

Agora precisamos testar a classe AlugaCarro e ver se de fato ela está retornando um objeto que possui as informações que esperamos que tenha.

Classe de teste

publicclass CarroAlugadoTest {

@Mock

private AlugaCarro alugaCarro;//my interface

public CarroAlugadoTest() {

alugaCarro = Mockito.mock(Cliente.class);

}

@Test

publicvoid alugaCarroParaCliente(){

//o caraquerecebeoscarrosalugados

CarroAlugado car = new CarroAlugado(alugaCarro);

String resultadoEsperado = “Camilo Golf”;

/*

* aqui o clientecamiloestáreservando o carro golf

*/

Mockito.when(alugaCarro.getNomeCliente()).thenReturn(“Camilo “);

Mockito.when(alugaCarro.getModeloCarro()).thenReturn(“Golf”);

String verdadeiroResultado = car.getAlugaCarro().getNomeCliente() + car.getAlugaCarro().getModeloCarro();

Mockito.verify(alugaCarro).getNomeCliente();

assertEquals(resultadoEsperado,verdadeiroResultado);

}

Explicado partes importantes do código

Passo 1

Precisamos fazer a mock,ou seja, “mockar” uma classe/interface, há várias formas de fazer isso, usaremos o modo mais simples, que é usar annotations @Mock na variável que vai ser o objeto e “instanciar” ela no construtor, pois quando a classe for carregada a variável será “mockada”.

@Mock

private AlugaCarro alugaCarro;

public CarroAlugadoTest() {

alugaCarro = Mockito.mock(Cliente.class);

}

Passo 2

Criamos um teste onde vamos verificar se um carro foi alugado para o cliente.

Primeiro passo foi passar o objeto “mockado” que representa “o cliente” para a classe CarroAlugado, pois é isso que ela espera receber, um objeto que alugou um carro.

  1. CarroAlugado car = new CarroAlugado(alugaCarro);

Em seguida vamos configurar os valores para o método que recebe o nome do cliente e o que recebe o nome do carro alugado. Porém, aqui usaremos API Mockito. Essa linha de código será executada quando o método for invocado.

  1. Mockito.when(alugaCarro.getNomeCliente()).thenReturn(“Camilo “);
  2. Mockito.when(alugaCarro.getModeloCarro()).thenReturn(“Golf”);

A leitura poderia ser algo do tipo: “quando o metodo getNomeCliente() for chamado, então configure o valor dele para “camilo”.

Na linha seguinte, observe que chamamos os métodos, que acreditamos estarem com um valor. E ai o mockito entra in action, quando um objeto, chama um daqueles métodos, ele configura os valores que estão no thenReturn().

  1. String verdadeiroResultado = car.getAlugaCarro().getNomeCliente() + car.getAlugaCarro().getModeloCarro();
  2. Mockito.verify(alugaCarro).getNomeCliente();

O método verify() apenas verifica se o método foi chamado, no API Docs do Mockito, há outras pessoas de verificação, como por exemplo:

  • verificar se o metodo getNomeCliente() foi chamado pelo menos 1 vez, ou mais vezes;
  • verificar se nunca foi chamado.

O assertEquals é somente para verificar se estamos recebendo o valor esperado.

Outro teste que foi implementado:

@Test

publicvoid verificaSeUmMetodoNuncaFoiExecutado(){

CarroAlugado carroAlugado = new CarroAlugado(alugaCarro);

Mockito.when(alugaCarro.getModeloCarro()).thenReturn(“Civic”);

//verificase o metodo getNomeCliente() nuncafoiexecutado

String modeloCarro = carroAlugado.getAlugaCarro().getModeloCarro();

Mockito.verify(alugaCarro, Mockito.never()).getNomeCliente();

}

Um video

Um video do Vinicius mostra a diferença entre mock & Stubs que achei muito bom.

http://viniciusquaiato.com/blog/diferenca-entre-mocks-e-stubs/

Conclusão

Uma outra dica é você gastar um bom tempo ali na documentação do Mockito, ela é bastante rica e de fácil leitura. A API não é tão grande e muito menos complexa, basta um pouco de pratica e sabendo como usar cada recurso, tá feito.

Vou ficando por aqui e espero que tenham gostado do post.

Abracos, see ya!

Mock com Mockito

Olá Pessoal,

Hoje vou apresentar o Mockito que é uma API de Mock, que tem ganhando espaço a cada dia. No post, vou falar pra que serve aos Mocks, o que evitamos e farei “reutilização da informação” sobre o que são mocks.  E para deixar tudo claro nada melhor que um exemplo feijão com arroz,  para que você possa entender como usar.  No próximo post veremos na pratica a criação de Mocks com Mockito.

Lets go…

Pra que serve o mockito?

Mockito  é uma API desenvolvida pela Google, com o objetivo de simular um objeto real para uma classe especifica. Isso pode ajudar nos testes de unidade quando precisamos verificar  a comunicação entre os objetos.

Por que usar Mock?

Usamos Mock quando temos classes que possuem dependencias, porém queremos testar apenas se uma classe está  retornando o que estamos esperando.

E o que evitamos usando mock?

Evitamos de ter que criar objetos para todas as dependencias de uma classe. Ou seja, com o mockito vamos “enganar” a execução do programa, dizendo pra ele que o objeto a ser passado é de fato o objeto que ele espera.

Na pratica

Antes de apresentar os códigos, vamos precisar pegar o conceito do “negócio” e saber como os códigos trabalham.

O cenário é o seguinte:

  • Class Cliente : um cliente ele possui alguns atributos como id, nome.
  • Classe CarroAlugado: esta classe tem como objetivo de informar/representar qual carro está alugado e para quem está alugado (cliente).  Então aqui já podemos ver que essa classe depende de um objeto da classe Cliente. Pois, um objeto da classe cliente que terá essas informações.
  • Interface AlugarCarro: temos uma interface que aluga carro, como o procedimento de alugar carro é sempre o mesmo, de ter o nome de quem está alugando  + o carro que foi alugado. Então se um cliente quiser alugar um carro terá que assinar um contrato com essa interface e informar pra ela o nome dele e o carro que deseja alugar.

E onde Mocks entram nessa história?

Mocs vão  entrar no momento que vamos simular que um cliente  c “Zezinhi” alugou um carro “Ferrari” e vamos ver se de fato  a classe tem essa reserva feita.

Os códigos a seguir:

public interface AlugaCarro {

      public void setNomeCliente(String nomeCliente);

      public void setModeloCarro(String nomeCarro);

      public String getNomeCliente();

      public String getModeloCarro();

}

Classe Cliente implementando a Interface, pois um cliente está querendo alugar um carro.

public class Cliente implements AlugaCarro {

      private String nomeCliente;

      private String modeloCarro;

      @Override

      public void setNomeCliente(String nomeCliente) {

            this.nomeCliente = nomeCliente;

      }

      @Override

      public void setModeloCarro(String nomeCarro) {

            modeloCarro = nomeCarro;

      }

      @Override

      public String getNomeCliente() {

            // TODO Auto-generated method stub

            return nomeCliente;

      }

      @Override

      public String getModeloCarro() {

            // TODO Auto-generated method stub

            return modeloCarro;

      }

}

A classe CarroAlugado  quer receber um objeto que foi instanciado contendo nome do cliente e o nome do carro alugado, e retornar esse objeto. Que nada mais é o Cliente que alugou o carro. Lembre-se o Cliente implements AlugaCarro, então temos o relacionamento HAS-A.  

public class CarroAlugado {        

      private AlugaCarro alugaCarro;

     public CarroAlugado(AlugaCarro alugaCarro) {

            this.alugaCarro = alugaCarro;

      }

      public AlugaCarro getAlugaCarro() {

            return alugaCarro;      }

      public void setAlugaCarro(AlugaCarro alugaCarro) {

            this.alugaCarro = alugaCarro;

      }    

}

Na edição 49 da revista MundoJ tem um artigo que escrevi junto com o Alexandre Gazola sobre o assunto. E lá detalhamos mais, eu sou suspeito de recomendar essa edição :).
vou ficando por aqui, espero que tenham gostado do post.

abracos, see ya!!

TDD:O seu primeiro TDD em Java

olá Pessoal,

Mais um post da śerie Agiile.Hoje veremos como escrever o seu primeiro TDD em Java (não é “o meu…”, pq este já fiz rs ), na semana passada eu dei um overview dos principios de TDD, nessa vamos praticar da maneira mais simples de ser. No próximo post, mostrarei como faço TDD hoje, após de algumas  “aulas” com o Kent Beck e o dia-dia fui aprimorando.Mas, não poderia de fazer um post para quem está no 0x0 do primeiro tempo :). (não sei pq,mas eu adorei a imagem que temos no inicio do post, passo horas olhando pra ela hehe)

lets go…

O foco

O foco aqui é poder compartilhar com vocês  de modo prático como foi que aprendi TDD. Pois, ainda há muitos programadores que não conseguem entender o uso, ou usar no dia-dia(claro que há exceções onde TDD não se aplica ,porém quando aplicamos este  já comprovou que os resultados são indiscutíveis).

O Exemplo

Antes de tudo vou buscar ser  bem direto ao foco do post e todo o conceito TDD será deixando de lado blz? Qualquer dúvida da uma passada no primeiro post ou no velho Google.

O nosso exemplo é o algo muito comum e escolhi ele, porque eu lembro como se fosse hoje, que  foi a partir dele que o mundo Agile marcou minha vida profissional, pois foi onde conseguir a dar meus primeiros passos ao desenvovimento guiado por testes.Sendo assim,resolvi usá-lo aqui no post. (não é nada chique, desde da faculdade, o que mais vemos é algo como RG, CPF, Locadora ,Estoque etc). Porém, o objetivo aqui não é saber se você sabe validar um RG,CPF,CNPJ, Locadora  etc. E sim se consegue desenvolver usando TDD.

Não esquecer

TDD não é apenas criar unit tests e sim ter testes inteligentes, ou seja, automatizados o suficiente para gritar quando alguém quebrar alguma regra. Outro detalhe não é pq são unit tests que você escreve de qualquer forma, é code então os principios são os mesmos utilizados no código funcional(não sei porque tem gente que separa isso, até hoje não entendi o motivo), na verdade quem desenvolve utilizando TDD tem um carinho enorme com seus testes, pois sabemos da importância deles durante o desenvolvimento e na manutenção. Já vi perguntas do tipo:

– pq não coloca tudo em um teste só? (será que precisa responder o motivo?)

– o que é um bom teste? (essa foi uma boa pergunta)

Primeiro que não há receita de bolo, mas um bom teste ele sempre tem um perfil parecido, grita de forma eficiente, ou seja, não grita por qualquer coisa que mudou, só grita quando algo que ele testa de fato mudou. Qual a diferença? Muita, há testes criados que tem varias responsabilidades e isso já passa ser um problema maior. Daí algo mudou e ele falha, mas a falha daria um novo teste especifico, mas o desenvolvedor que só escreve teste por escrever ou pq é mandatório no projeto, e importante que o teste esteja lá como métrica.

Enfim, Um bom teste deve ser especifico e rápido, assim vc pode executá-lo várias vezes.Isso é algo primário que precisamos ter em mente ao construir nossos testes.

Praticando

No exemplo a seguir temos uma aplicação que faz a “validação” de um nro de uma carteira de identidade. Este é um start-up para você ficar brincando após brincando após a leitura, mas terá que ser persistente e ir mais adiante para olhar o que tem  após omuro. Se não fizer foi ai onde quase todos desistiram.

Primeiro passo

Escrevemos a classe de teste e já fizemos o teste para os possíveis RG inválido/válido.

public class RGTest extends TestCase {

private RG validarg = new RG();

publicvoid testIsValidaRG(){

assertFalse(“retorna FALSE – inválido RG”, validarg.isValidaRG(“128641011”));

assertFalse(“retorna FALSE – RG inválido”, validarg.isValidaRG(null));

assertFalse(“retorna FALSE – RG inválido”, validarg.isValidaRG(“”));

assertTrue(“retorna TRUE – RG válido”, validarg.isValidaRG(“128640-28”));

}

Se for executado vai falhar porque não temos a classe principal “RG” que precisamos implementar. A falha anterior é de compilação, caso você execute.

public class RG {

publicboolean isValidaRG(String rg){

return false;

}

Segundo Passo

Agora precisamos testar e ver se vai falhar, pela teoria deve falhar.

O motivo da falha é que o método isValidaRG(String rg) sempre retorna false, então, nosso teste não está funcionando 100%. Pois, precisamos ter um nro de RG válido.

Terceiro passo

Fazer o teste funcionar, precisamos resolver o problema de ter um RG válido, para isso precisamos alterar o método da classe principal.

public boolean isValidaRG(String rg){

if((rg== null) || (rg.length()!=11)|| (rg.isEmpty()) || rg.charAt(8)!= ‘-‘){

return false;

}

return true;}

Agora estamos validando, os nossos assertXXX da classe teste.

O Bug

O código abaixo passa no teste, observe que não há nenhuma regra validando letras, e sabemos não existe RG com letras. Precisamos criar um teste para isso. E resolver o bug

assertTrue(validarg.isValidaRG(“abcdefgh-ij”));

Quarto passo

criamos um método na classe RGTeste para testar se de fato nossa aplicação NÃO aceita letras, mas pelo resultado abaixo, vimos que aceita, uma vez que o método retorna TRUE, já que não há nada que proíba as letras na classe principal.

//criando um novo método para testar letras

publicvoid testIsValidaRGLetras(){

assertFalse(“retorna FALSE – inválido letras RG”, validarg.isValidaRG(“ABCDEFGH-IJ”));

assertFalse(“retorna FALSE – Inválido letras RG”, validarg.isValidaRG(“G3X8Xopa-22”));}

 Quinto passo

Precisamos agora alterar isso no código principal, para testar que letras não podem passar pelo metodo.

public boolean isValidaRG(String rg){

if((rg== null) || (rg.length()!=11)|| (rg.isEmpty()) || rg.charAt(8)!= ‘-‘){

return false;

}//fim do if

for (int i = 0; i < rg.length(); i++) {

if(i!=8){

char posicao = rg.charAt(i);

//senao for umdigitoretorne false

if(!Character.isDigit(posicao)){

return false;

}}

}return true;

}

Ambos testes passaram, assim sabemos que a validação de RG está correta, até agora. Porém, o que devemos observar que nessa mecânica, fomos escrevendo o nosso código com base nos resultados dos unit tests primeiro e não fazer o inverso. É obvio que falta muito trabalho ainda até termos um RG realmente válido e inválido, mas lembre-se que o básico de TDD é querer fazer a barra verde chegar o quanto antes com o menor esforço possível, é um tal de baby-step. É comum, queremos implementar logo a parte complexa do código, querendo fazer as validações possíveis etc. Mas, é ai que o terreno está propicio para nascer os bugs mais terríveis de nossa vida e só saberemos quando o cliente abrir. Encontrar bugs em modelo como waterfall não é uma tarefa fácil, não é a toa que o custo de manutenção nesse modelo é alto. Lembre-se que devemos desenvolver algo que qualquer outro desenvolvedor possa entender no menor tempo possível, e TDD possibilita isso, eu particularmente, quando pego um código feito com TDD olho primeiros os testes. Os testes sãos os guias que precisamos. :).

 Meu case

No exemplo do post vimos como usar TDD, quando iniciei meus estudos nunca parece vantagem (acho que você deve está com esse sentimento também), olhando apenas a execução e o resultado. Mas, confesso que só conseguir ver a essência de TDD em partes diferente do projeto, uma quando precisamos alterar algo, e manter os testes passando, ou quando recebia novos requisitos e tinha que implementar e criar mais testes, ai vi agilidade em pratica e ficando viciado, sem falar que todo time fica feliz, pelo tempo gasto na manutenção, TDD de fato dar contribuição dele na manutenção de software. Fora que com o tempo vamos vendo o quanto TDD ajuda na construção do nosso design. Daí passamos a ter um tal de design incremental.

Espero que tenham gostado do post, vou ficando por aqui, até o próximo post.

Abracos, see ya!!