Ah, beleza. O aplicativo está funcionando e não aparentou nenhum problema aparentemente… Só aparentemente… Chegou na hora do “vamos ver”, apareceu um bug muito estranho. Ela não estava calculando corretamente. Depois da apresentação, olhei o código-fonte e vi que estava chamando uma função com os parâmetros invertidos!

Puts, bateu a raiva: eu devia ter desenvolvido com testes unitários. Mas não fiz por preguiça…

O que vem a ser um teste unitário? Um teste unitário é um tipo de teste que se concentra na verificação da menor unidade do projeto de software, como por exemplo, parâmetros, saídas, valores de retorno, exceções ou o estado do objeto. Essa categoria de testes não procura testar toda a funcionalidade de uma aplicação, que fica a cargo de outros testes, como de integração ou de performance.

E o JUnit? Ele é um framework open-source que possibilita a criação de testes unitários em Java. Como a maioria das IDEs incorporam o JUnit dentro de seu ambiente de desenvolvimento, fica fácil usar esse framework.

Um pequeno exemplo (idiota, mas um exemplo):

Vamos supor que no meu aplicativo eu quero uma classe Operacoes que contem métodos para realizar as 4 operações básicas da matemática. (Usarei o Netbeans 6.1)

Eu começo criando a classe Operacoes e escrevo só a assinatura do método:

// Operacoes.java
public class Operacoes {
    public static int soma(int v1, int v2) {
        return 0;
    }
    public static int subtracao(int v1, int v2) {
        return 0;
    }
    public static int multiplicacao(int v1, int v2) {
        return 0;
    }
    public static int divisao(int v1, int v2) {
        return 0;
    }
}

Agora escrevo os testes… Você deve estar se perguntando? “Hã?” Mas és assim mesmo. Primeiro escrevemos os testes e depois implementamos os métodos.

Seleciono o arquivo no Netbeans e aperto Ctrl+Shift+U. Aparecerá o seguinte:

Escolha a versão 4.x. É mais simples. Depois, ele pede que teste você deseja criar:

Se você olhar esse novo arquivo que ele criou, verá métodos do tipo:

@Test
public void testSoma() {
}

@Test é uma anotação. Ele diz que o método seguinte é um teste.

O JUnit utiliza provê vários métodos assertivos para avaliar os testes. No site oficial, existe a documentação, mas é da versão 4.5. Talvez hajam algumas diferenças.

Voltando ao exemplo, como são feitas as asserções?

Para verificar objetos, podemos usar o método assertEquals. Uma versão desse método que eu mais gosto de usar é assertEquals(String message, Object expected, Object actual). O primeiro parâmetro message é a mensagem que aparece quando o teste falha, expected é o objeto que o método deveria retornar e actual é o que o método retornou.

Meu método testSoma poderia ficar assim:

@Test
public void testSoma() {
   assertEquals("2+2 falhou", 4, Operacoes.soma(2, 2));
   assertEquals("10+5 falhou", 15, Operacoes.soma(10, 5));
   assertEquals("12+13 falhou", 25, Operacoes.soma(12, 13));
}

Pronto, escrevi o teste. Se eu rodar ele (Alt+F6) recebo uma bonita mensagem de erro

E assim eu faço com os outros métodos de teste:

// OperacoesTest.java
import org.junit.Test;
import static org.junit.Assert.*;

public class OperacoesTest {
  @Test
  public void testSoma() {
    assertEquals("2+2 falhou", 4, Operacoes.soma(2, 2));
    assertEquals("10+5 falhou", 15, Operacoes.soma(10, 5));
    assertEquals("12+13 falhou", 25, Operacoes.soma(12, 13));
  }

  @Test
  public void testSubtracao() {
    assertEquals("4-1 falhou", 3, Operacoes.subtracao(4, 1));
    assertEquals("4-6 falhou", -2, Operacoes.subtracao(4, 6));
    assertEquals("10-2 falhou", 8, Operacoes.subtracao(10, 2));
  }

  @Test
  public void testMultiplicacao() {
    assertEquals("2*3 falhou", 6, Operacoes.multiplicacao(2, 3));
    assertEquals("6*0 falhou", 0, Operacoes.multiplicacao(6, 0));
  }

  @Test
  public void testDivisao() {
    assertEquals("4/2 falhou", 2, Operacoes.divisao(4, 2));
    assertEquals("2/5 falhou", 0, Operacoes.divisao(2, 5));
  }
}

Pronto, meu testes estão prontos (por enquanto). E todos falham.

Nokia E51

Frequência de operação: WCDMA 2100 / WCDMA 850 / GSM 850 / 900 / 1800 / 1900
Bandas: WCDMA/ GSM
Tecnologias suportadas: XHTML, HTML, MMS, Java MIDP
Sistema operacional: S60 3rd Edition Feature Pack 1 baseado no Symbian OS v9.2
Dimensões: 115 x 47 x 12 mm
Peso: 100 g

Tela
Resolução: 240 x 320
Quantidade de cores: 24 bit (~16 milhões)

Câmera
2 megapixel
Grava vídeos em 15 fps

Memória
No celular: 120 MB
Até 4 GB com cartão de memória microSD
Aceita JAR de qualquer tamanho

Navegação
HTML sobre TCP/IP
Navegador S60 OSS
WAP 2.0
XHTML sobre TCP/IP

Mensagens
MMS+SMIL
SMS
MMS

Java
MIDP 2.0
CLDC 1.1
JSR 135 Mobile Media API
JSR 172 Web Services API
JSR 177 Security and Trust Services API
JSR 179 Location API
JSR 180 SIP API
JSR 184 Mobile 3D Graphics API
JSR 185 JTWI
JSR 205 Wireless Messaging API
JSR 226 Scalable 2D Vector Graphics API
JSR 234 Advanced Multimedia Supplements
JSR 75 FileConnection and PIM API
JSR 82 Bluetooth API
Nokia UI API

Formatos de áudio
AAC, AAC+, eAAC+, MP3, MP4, M4A, AMR-NB, AMR-WB, Mobile XMF, SP-MIDI, MIDI (poly 64), RealAudio 7,8,10, True tones

Formatos de vídeo
3GPP (H.263)
H.264/AVC
MPEG-4
RealVideo 7,8,9/10

DRM
OMA DRM Forward Lock
OMA DRM v1.0
OMA DRM v2.0
DRM via: download HTTP, MMS, download OMA

Tipos de rede suportados

UTMS (3G)
HSDPA (3.5G)
WCDMA
EGPRS
GPRS
HSCSD
CSD

Conectivade com o PC
Bluetooth
Infravermelho
Mini USB (não é o formato proprietário da Nokia)
WLAN (com suporte a conexões ad-hoc)

Implementar uma calculadora lógica que aceite como entrada os símbolos:

• T - Verdade
• F - Falso
• ^ - Conjunção
• v - Disjunção
• ~ - Negação
• -> - Condicional
• <-> - Bicondicional
• ( ) - Parentização

A calculadora deve avaliar a expressão, considerando as precedências e apresentar o resultado lógico.

Deve se desenvolvida em C, Java, Haskell, Lua, LISP ou Python, e os grupos podem conter até 4 pessoas.

Na verdade, ele só nos tinha dado a opção de fazer em C ou Java, mas depois de muita insistência, ele liberou as outras linguagens (que por sinal, dessas eu só programo em Python).

No início, nos pairava a dúvida: “Pqp, como vamos validar essa porr*?” Ah, expressões regulares… A oitava maravilha do mundo… Simples assim… Peraí… Simples? Eu disse simples? Você acha que a expressão abaixo é simples? (Ela já está com as barras invertidas devidamente escapadas)

“^(~*[(]*?|([FT]|[(]*[~]*?[FT])[)]*?(V|\\^|->|<->)[(]?~?[(]?)*(F|T|[FT][)]*)$”

Pois é meu amigo… Parafraseando o Kibe Loco (site que, aliás, não acesso) “a verdade é ácida e o kibe é cru”. Beleza então, a classe String do Java (sim, fizemos em Java), tem um método matches para comparar a String com uma regex.

Mas quem diria hein? O Java apanha pra validar uma expressão lógica (não é a regular!) com mais de 40 caracteres. Tá, o cara tem que ser meio louco para fazer uma expressão lógica com 40 caracteres… Mas é lento!

Ok, passado o trauma a dificuldade inicial, veio o segundo problema: e como resolver? Puts, mais essa agora… Depois de um tempinho, veio a resposta: o Shunting yard algorithm (slides feitos por mim) funciona excepcionalmente bem… E é muito simples de ser implementado. O “coração” do programa está aqui, comentado linha por linha.

Aos meus colegas de sala, fica aqui a dica. Aos outros, sim, esse é mais um post inútil.

Repositório no GitHub, link direto para a pasta do código-fonte, link para o pseudo-executável (.jar).

Em, praticamente, qualquer curso envolva o desenvolvimento de sistemas, ensina-se a desenvolver um projeto usando 5 grandes fases:

• Definição: onde são definidos os requisitos do projeto. Na maioria da vezes, é aqui que acontecem as conversas com o cliente, para levantar todas as suas necessidades;
• Projeto: com os requisitos em mãos, começamos a estruturar as telas, os dados e os planos de testes;
• Codificação: é a fase onde a programação é de fato feita;
• Testes: necessários para garantir que a codificação tenha sido feita apropriadamente;
• Implementação: é o momento de colocar o sistema em produção.

Essa metodologia de desenvolvimento é conhecida como “cascata” (waterfall em inglês), pois cada fase depende da fase anterior para acontecer. Uma conseqüência desse método é que quanto mais avançado estiver o desenvolvimento de sistema, maior será o custo de alterar o projeto, custo esse que pode vir de diferentes formas, tais como corte de funcionalidades, corte de qualidade de desenvolvimento, aumento de prazos e conseqüente aumento de valores. Coisa que prejudica o relacionamento com o cliente.

Desenvolvimento em cascata só funciona em ambientes bem definidos e compreendidos.

Mas e então? Existe alternativa?

Sim, e esses são os métodos de desenvolvimento ágil.

O ágil é um conjunto de processos para desenvolvimento desoftware que usa conceitos como:

• Iteratividade
• Técnicas incrementais
• Auto-gerenciamento
• Auto-organização
• Pessoas

O ágil olha menos para processo e foca mais no que pessoas podem fazer para obter os resultado. É também:

• Propício à mudanças
• Mais colaborativo
• Planejamento constante
• Entregas mais rápidas
• Comprometimento da equipe
• Adaptado a realidade

Existem várias metodologias para desenvolvimento ágil, mas sem dúvida, a mais conhecido é a XP.

Fontes: Metodologias Ágeis de Desenvolvimento - Locaweb, railsbox via twitter.

Para isso foi criado este domínio. Ele hospedava um wiki e um fórum onde os participantes discutiam sobre os enigmas.

Domínio free já viu né? Tem que haver tráfego… Então, hospedei meu blog pessoal aqui.

Mais detalhes sobre o ARG, você encontra aqui.

Sobre o autor

O cara aqui do outro lado é um geek que cursa Sistemas de Informação. Adoro assuntos polêmicos, novidades e qualquer coisinha feita em AJAX com uma “etiquetinha” escrito beta.

Eu desenvolvo em Java, Python e me viro com HTML, XHTML, PHP e CSS.

Bom, pra um post inicial, acho que é o suficiente.