29 de maio de 2012

Conexão Java 2012



Domingo, dia 27/05 aconteceu o Conexão Java, um evento para quem está começando com esta linguagem de programação.
Todos os temas foram interligados por um problema comum (o que foi uma ótima sacada) e as apresentações seguiram desse problema.

09:00 - Começou com a palestra Java por dentro com Paulo Silveira
09:45 - Foi a vez do Mauricio Aniche com a palestra Boas práticas de Orientação a Objetos
11:00 - Cecília Fernandes deu a palestra Conhecendo melhor as Collections
11:45 - A Web: Component Based com JSF com Alberto Souza
14:00 - A Web: o Action Based com Vraptor do Adriano Almeida
14:45  - Guilherme Silveira destruindo com a palestra Sua primeira aplicação com JPA e Hibernate
16:00  - Seguiu a palestra Colocando nossa aplicação no Cloud com Hanneli Tavante
16:45  - Palestra feita por Erich Egert - Criando uma aplicação Mobile para Android
17:30 Foram a vez das Lightning talks com o pessoal do GUJ:
          - Desenvolvendo RIA com Java e EXT GWT - Loiane Groner
          - Cultura da empresa, um problema na adoção ágil - Eduardo Bregaida
          - Aprendi Android, e agora? - Fernando Boaglio
          - Jogos com Android - André Silva
          - Minha primeira aplicação iOS em (quase) 5 minutos - Ricardo Valeriano e Diego Chohfi
          - Sérgio Lopes trollando e sorteando os prêmios

Valeu muito a pena ir, rever os amigos, ver o pessoal empolgado que está começando com Java, o evento contou com 400 pessoas, toda organização feita pela Caelum.
Os fontes das palestras estão disponíveis no GitHub do Conexão Java.
Outra novidade foram as apostilas abertas da Caelum em formato de livros.

Também foi comemorado os 10 anos de GUJ e os 8 anos da Caelum.

O Conexão Java 2004 foi o segundo evento que participei, abriu muitas portas e conheci muitas pessoas, aprendi muito e valeu a pena, meu conselho é: "Vá, participe de eventos, converse com as pessoas que estão em volta, você não irá se arrepender".
Fiquei muito feliz em participar, ano que vem, estarei novamente no evento.

No Blog da Caelum, também há um post sobre o evento.
Algumas fotos no meu Flickr.

4 de maio de 2012

TDD - Test Driven Development

http://xion.org.pl/wp-content/uploads/2012/02/tdd.png

Pessoal, hoje vou postar sobre TDD, vejo muitas discussões e dúvidas sobre como desenvolver utilizando esta prática, espero sanar algumas delas, assim como tentar passar o modo que o utilizo no meu dia a dia.

TDD (Test Driven Development - Desenvolvimento Orientado a Teste) a forma como aprendemos a programar normalmente é:
 Desenvolvo o código e quando termino, testo, fazendo isso estamos arriscados a deixar uma grande quantidade de Bugs passar, muitas vezes esses erros acabam entrando em produção e o custo da manutenção ficará muito caro.

Ok, mas como deveria ser feito?
A resposta é: devemos começar com os testes, antes mesmo de criar as classes do sistema e é aí que sinto que muitos (assim como também senti no início) encontram dificuldades.

Como começar com os testes? Como vou saber o que minha classe vai ter?

Não precisamos saber tudo de uma vez, conforme eu desenvolvo um teste, crio e implemento as classes que serão testadas, por exemplo:

OBS: Para esses testes utilizei apenas o JUnit com a IDE Eclipse, não utilizei Mocks para esse caso.

Tenho um sistema de calculadora, nessa calculadora preciso das 4 operações matemáticas (adição, subtração, divisão e multiplicação) para calcular 2 números.

Por onde começo?
Vamos criar a classe de teste (Crie como uma classe JUnit New -> JUnit Test Case), eu chamei de FuncaoTest, dentro eu criei o primeiro método que se chama: deveriaSomarDoisNumeros.

Por que esse nome? Para ser simples, quero testar a adição de dois números, então, eu digo o que meu teste deveria fazer naquele método.

Nosso primeiro método ficou assim:
@Test
    public void deveriaSomarDoisNumeros() throws Exception {
        resultado = funcao.soma(2,2);

        Assert.assertTrue(resultado==4);
    }
Mas eu não possuo a classe Funcao.java ainda, então vamos criá-la (New -> Class) e dentro da classe criaremos o método soma:
public int soma(int primeiroValor, int segundoValor) {
        return primeiroValor+segundoValor;
    }
Agora vamos rodar o teste e ver o resultado (Run As -> JUnit Test):





Verde significa que nosso teste foi executado com sucesso.
Pronto, você conseguiu fazer seu primeiro teste, agora dando seqüência vamos criar a função de subtração, segue o mesmo passo anterior, vá no teste e crie o método deveriaSubtrairDoisNumeros, implemente o método na classe Funcao:

Método do teste deve ficar assim:
@Test
    public void deveriaSubtrairDoisNumeros() throws Exception {
        resultado = funcao.subtrai(2,2);

        Assert.assertTrue(resultado==0);
    }
E o método de subtração deve ficar assim:
public int subtrai(int primeiroValor, int segundoValor) {
        return primeiroValor-segundoValor;
    }
Claro que quando rodarmos o teste, a barra mostrará verde, mas e se durante o copy/paste nós fizessemos isso:
public int subtrai(int primeiroValor, int segundoValor) {
        return primeiroValor+segundoValor;
}


 O resultado seria isso:


 Durante nosso dia a dia, temos a mania de copiar e colar métodos que se parecem e fazer as alterações neles para que se comportem como esperamos, mas se nesse monte de copia e cola nós esquecessemos de mudar o sinal? Sem a classe de teste, só descobriríamos esse bug após o desenvolvimento ter terminado.

Mais uma observação, notaram que durante essa criação o teste contém elementos que duplicamos?
Notem a classe Função sendo instânciada duas vezes Funcao funcao = new funcao(); como vamos chamá-la sempre podemos instânciá-la logo no início, também notem que todos os métodos tem retorno int resultado, este também pode ser declarado no início da classe fora dos métodos, nossa classe de testes ficaria assim:
public class FuncaoTest {

    private Funcao funcao;
    private int resultado;
   
    @Before
    public void setUp() throws Exception {
        funcao = new Funcao();
    }
   
    @Test
    public void deveriaSomarDoisNumeros() throws Exception {
        resultado = funcao.soma(2,2);

        Assert.assertTrue(resultado==4);
    }
   
    @Test
    public void deveriaSubtrairDoisNumeros() throws Exception {
        resultado = funcao.subtrai(2,2);

        Assert.assertTrue(resultado==0);
    }
}
O @Before, fará a instância da classe para nós, isso de tirar a instância de todos os métodos e reescrever de uma forma que torne nosso método mais simples e prático, isso é chamado de Refatoração.
Quando utilizamos TDD, devemos sempre nos lembrar de seguir essa regra nos testes: Test Red, Test Green and Refactoring, ou seja, nós esperamos sempre que nosso teste falhe, depois corrigimos e após a correção, aplicamos refatoração e testamos novamente para ver se os métodos ainda estão funcionando.
Refatorar é reescrever um código, melhorando sua estrutura e mantendo a mesma funcionalidade.

http://www.testically.org/wp-content/uploads/2011/01/TestDrivenGameDevelopment.png


Para os métodos de divisão e multiplicação, basta seguir este mesmo conceito.
A classe de teste deverá ficar assim:
public class FuncaoTest {

    private Funcao funcao;
    private int resultado;
  
    @Before
    public void setUp() throws Exception {
        funcao = new Funcao();
    }
  
    @Test
    public void deveriaSomarDoisNumeros() throws Exception {
        resultado = funcao.soma(2,2);

        Assert.assertTrue(resultado==4);
    }
  
    @Test
    public void deveriaSubtrairDoisNumeros() throws Exception {
        resultado = funcao.subtrai(2,2);

        Assert.assertTrue(resultado==0);
    }
  
    @Test
    public void deveriaDividirDoisNumeros() throws Exception {
        resultado = funcao.divide(2,2);

        Assert.assertTrue(resultado==1);
    }

    @Test
    public void deveriaMultiplicarDoisNumeros() throws Exception {
        resultado = funcao.multiplica(2,2);

        Assert.assertTrue(resultado==4);
    }
}
E a Classe Funcao deverá ficar assim:
public class Funcao {

    public int soma(int primeiroValor, int segundoValor) {
        return primeiroValor+segundoValor;
    }

    public int subtrai(int primeiroValor, int segundoValor) {
        return primeiroValor-segundoValor;
    }

    public int divide(int primeiroValor, int segundoValor) {
        return primeiroValor/segundoValor;
    }
  
    public int multiplica(int primeiroValor, int segundoValor) {
        return primeiroValor*segundoValor;
    }
}
Bem lembrado pelo meu amigo Rafael Afonso, se a pessoa dividir por zero? Como poderia fazer meu teste?

A Solução ficaria desta forma:
@Test(expected = ArithmeticException.class)
    public void deveriaDividirDoisNumerosComExcessao() {
        resultado = funcao.divide(2,0);
        Assert.fail("Não deveria dividir por zero! " + resultado);
    }
Podemos testar também nossas exceções: Adicionamos o atributo 'expected' com a classe da exceção esperada.


Conclusão:
Esse foi apenas o ínicio da sua aventura com TDD, no final vou colocar alguns links interessantes, acostume-se a começar seu desenvolvimento pelo teste, não saia fazendo tudo loucamente, refatorem sempre, estude também Mocks, atualmente utilizo Mockito, um ótimo framework para mockar os objetos, entenda mockar como criar objetos falsos para facilitar nossos testes em camadas.

Links Úteis:
http://improveit.com.br/xp/praticas/tdd
http://www.slideshare.net/eduardo.bregaida/refatorao-de-cdigo-com-capito-nascimento-verso-completa
http://blog.caelum.com.br/facilitando-seus-testes-de-unidade-no-java-um-pouco-de-mockito/
http://rodrigomaia.net/2011/09/27/conhecendo-testes-unitarios-com-junit4/
http://blog.fragmental.com.br/2007/10/31/programadores-profissionais-escrevem-testes-ponto-final/
http://www.devmedia.com.br/junit-implementando-testes-unitarios-em-java-parte-i/1432
http://www.devmedia.com.br/junit-implementando-testes-unitarios-em-java-parte-ii/1549
http://rodrigomaia.net/2011/09/27/mock-objects-com-mockito/