TDD - Desenvolvimento Guiado por Testes

Sei que esse assunto já foi e é explorado em n locais de n diferentes formas, mesmo assim vejo gente "confundindo tudo" e perguntas do tipo:

• Posso usar DDD com TDD? (sim)
• TDD pode ser usado em processos não-ageis? (sim)
  
• TDD não é perda de tempo? (eu acho que não)
  
• Faço testes no meu processo, estou usando TDD? (depende)
  

A teoria de testes no desenvolvimento de sistemas é extensa, neste pequeno post não será possivel explicar cada conceito por tras dela ao contrário disso irei tentar explicar apenas o Ciclo (descaradamente inspirada no exemplo do livro).

Ciclo
1º Adicione um teste
Antes mesmo de criar o código real que irá ser testado.
2º Rode os testes e veja se os novos falham
Primeiro faça o teste falhar, geralmente escrevemos código falso.
ex: assertEquals("esperado",objeto.getRetornaNull());
3º Escreva um pouco de código
Escreva um pouco de código para fazer o teste funcionar.
4º Rode os testes automatizados e os veja funcionando
Agrege-os a sua base de testes automatizados (que pode ou deve ser rodado sempre num processo de build automatizado também).
5º Refatore o código
Agora você pode ter o tempo pra dar uma melhorada no design atual, refatoração é a ordem.
ps: refatore tanto o código da aplicação quanto os testes.
6º Volte para o passo 1
Apenas a repetição do processo. (claro que em uma nova estoria/caso de uso/whatever)

Pra finalizar minha opinião: testes são tão importantes quanto o código final . (é algo que atesta sua qualidade executavel.) ahh e leia um bom livro sobre TDD acredito que irá achar a leitura agradavel.

Regras de negócio OO vs Condicionais

O que é uma regra de negócio ?
São todas as regras existentes num sistema de informação, que ditam seu comportamento, suas restrições e validações. ( Wikipédia )

Imaginemos um sistema de cadastro de usuários (com regras bem pobres, mas que já são o bastante pra exemplificar a construção de regras no software) um conjunto válido de regras poderia ser:

1 - Só se pode cadastrar usuário que tem o nome de usuário com mais de 6 letras.
2 - As senhas deverão ter no mínimo 6 letras e no máximo 8 letras.
3 - Só será possível logar no sistema aqueles usuários que informarem a data de nascimento deles.

Condicionais

Numa abordagem condicional poderiamos ter.

if (! facade.cadastrar(usuario)){
showMessage("Erro ao cadastrar");
}

public boolean cadastrar(Usuario usr){
if (usr.nomeUsuario.length()<=6){
return false;
}
if (usr.senha.length()<6>8){
return false;
}
return true;
}

Mais oo

As regras estariam (ou deveriam) no próprio objeto e ele deveria reger todas as chamadas à ele.

public void setNomeUsuario(String user){
if (user.length() <=6) throw new NomeUsuarioInvalidoException("O nome deve conter no mínimo 7 letras.");
}

O simples fato de dar comportamente a quem interessa tal comportamente (GRASP) já é um avanço nos projetos de software. A maioria dos desenvolvedores ficam encantados com Spring ou mesmo discutindo qual melhor uso dos Daos ou Repositorios mas quase todos se esquecem que um bom projeto é o simples fato de entender e modelar os problemas da maneira mais adequada ao seu contexto. (seja oo, xx , ss ou yy)

* Tente sempre que possível codificar suas regras de negócio nos objetos (entidades).
* Não dito que usar if's é errado mas que pode ser um "cheiro" de que algo está errado ou caminhando pra rumo errado.
* O título ficou meio idiota no fim programas são sempre "condições" todavia não uma enxurada de condições encuraladas.

JChip8BR

Chip8 e SChip8 escritos em Java

Chip8 é o projeto padrão para aqueles que desejam se iniciar no desenvolvimento de um emulator (ou máquina virtual, ou misto de simulador com emulação ou etc.) Este projeto é outro exemplo de como implementar essa "máquina". A linguagem que escolhi foi Java e pra renderizar usei o Java2D mesmo. Um simples (mas usual) debugador está também no JChip8BR e uma ferramenta (essa acho que pode ajudar) de "disassemblar" com o assembler em duas notações a do David Winter e do Michael Toren.

Screenshots


Página do projeto
JChip8BR

Java e os tipos sem sinais (unsigned types)

"A grande maioria dos desenvolvedores Java (bem como outras linguagens tipadas) quando necessitam representar algum número inteiro provavelmente usam int. Antigamente as pessoas tinham maiores preocupações com a quantidade de memória disponível, hoje nem tanto. Contudo há uma nova gama de aplicações pra celular surgindo e nesses casos otimização é uma obrigação."

(alguém me disse isso em algum momento...)

Se fossemos criar um atributo pra representar o número de cadeiras numa sala (tendo em vista que está sala não suporta mais de 240 cadeiras) poderíamos usar int, short ou byte. (claro que aqui caberiam outros tipos como char, String, double... )

Usar int ou short seria desperdício de memória!
Logo podemos utilizar byte?!

Nem tão rápido, 1 byte pode caber "256" números diferentes...
Em Java o byte tem 256 "posições" mas essas são preenchidas com os seguinte números -127 a 127.

Ou seja se você somar:
byte x = 127;
byte y = (byte)(x + 1);
System.out.println("x="+x);
System.out.println("y="+y);
você terá, ao invés de 128, y = -127.

O Wraparound do tipo byte
Com sinal:
-127 .. -100 .. 0 .. 1 .. 127 (127 + 1 == -127)

Sem sinal:
0 .. 100 .. 200 .. 255 ( 255 + 1 == 0)

Como extrair o byte sem sinal de um byte em Java? (tem como retornar o valor sem sinal?)

Simplesmente :
public static short readUnsignedByte(byte value){
return (short) (value & 0xff);
}

Se você passar -127 o método vai devolver o 128 e assim por diante. (claro que o retorno é short e não byte.)

Os altos e baixos da qualidade na conexão 3G! - parte 2

Os altos e baixos da qualidade na conexão 3G!

O post do link acima... foi escrito há um tempo atrás...
Depois disso tive experiências com outras operadoras e outros modelos de modems.
Estou assustado com a melhoria de qualidade quando, usando a mesma brt, troquei de modem (um modelo mais novo). Claro que também pode ter sido que o sinal 3G na minha região tenha melhorado e não o modem.

Esse novo modelo de modem, que está na forma de um pendrive da cor branca, parece aceitar mais um protocolo de comunicação (além de demonstrar uma clara melhoria na "escolha automática" dos mesmos).

Como não tenho o velho modem (o da cor preta com formato retangular) pra testar não posso apenas lhe dar um conselho (tipo, troque de modem), mas se for possível à você realize um teste com esse "novo modelo" da zte.

Brincando com constantes

Tudo começa com um simples programa que imprime o nome e o sobrenome.

package exemplo.entidade;

public class Testadora {

public static void main(String[] args) {
mostrarNome();
mostrarSobrenome();
}

private static void mostrarSobrenome() {
System.out.print("Sobrenome ");
}

private static void mostrarNome() {
System.out.print("Nome ");
}

}


Alguém resolve fatorá-lo, resolve deixar tudo em um único local.

package exemplo.entidade;

public class Testadora {
public static final int NOME = 10;
public static final int SOBRENOME = 20;

public static void main(String[] args) {
mostrarNome();
mostrarSobrenome();
}

private static void mostrarSobrenome() {
mostrar(SOBRENOME);
}

private static void mostrarNome() {
mostrar(NOME);
}

private static void mostrar(int tipo) {
if (tipo==NOME){
System.out.print("Nome ");
}else if(tipo==SOBRENOME){
System.out.print("Sobrenome ");
}
}

}

A principio parece estar agregando mais complexidade a algo que deveria simplesmente fazer algo trivial. Um terceiro resolve retirar os "mediadores".

package exemplo.entidade;

public class Testadora {
public static final int NOME = 10;
public static final int SOBRENOME = 20;

public static void main(String[] args) {
mostrar(NOME);
mostrar(SOBRENOME);
}

private static void mostrar(int tipo) {
if (tipo==NOME){
System.out.print("Nome ");
}else if(tipo==SOBRENOME){
System.out.print("Sobrenome ");
}
}

}

Um quarto metido a espertinho realiza uma mudança que deixa o código bem mais simpático.

package exemplo.entidade;

public class Testadora {
public static final int NOME = 10;
public static final int SOBRENOME = 20;

public static void main(String[] args) {
mostrar(NOME+SOBRENOME);
mostrar(NOME);
mostrar(SOBRENOME);
}

private static void mostrar(int tipo) {
if (tipo==NOME){
System.out.print("Nome ");
}else if(tipo==SOBRENOME){
System.out.print("Sobrenome ");
}if (tipo==NOME+SOBRENOME){
System.out.print("Nome Sobrenome ");
}
}

}

Fica simples e objetivo o propósito mostrar o nome e o sobrenome. :)

ps: favor notar que o post não discute o fato de usar ou não polimorfismo, apenas mostra um modo elegante de se aproveitar o uso de constantes.