Embora já tenha quase 7 anos de experiência em desenvolvimento de software, até hoje nunca trabalhei em uma empresa que se preocupasse muito em estar atualizada em termos de qualidade de software, o que ainda me frustra um pouco. Sendo assim, me dedico nas minhas "horas vagas" a estudar para ser um engenheiro de software ou simplesmente um profissional melhor, como diz o Alexandre Gomes.
Ultimamente, me entreguei à experimentação de TDD (Test Driven Development). Já tinha ficado muito entusiasmado quando aprendi sobre testes unitários automáticos, pelos motivos já amplamente citados em qualquer pesquisa sobre o assunto que você fizer no google. Agora experimentando TDD me dei conta de outra coisa, talvez óbvia para quem é experiente TDDista: TDD te leva, ou melhor, literalmente te induz, diretamente, implicitamente, a manter o foco no DOMÍNIO. Quem entende essa outra sigla de 3 letrinhas aqui: DDD, sabe do que eu estou falando. Raciocínio simples: com TDD você implementa requisitos (ou histórias) funcionais do seu cliente. Cada teste é um requisito. Quando você conversa com seu cliente sobre qual o problema que ele quer resolver, ele dirá mais ou menos assim:
- Preciso de um sistema que controle minhas vendas.
- Hum, beleza. Como é o seu método de vendas?
- Simples. Criamos um pedido de acordo com o especificado pelo cliente. Depois que está tudo ok, emitimos a nota fiscal e enviamos a mercadoria.
- Ok. E o que faz "tudo ficar ok"?
- Ah. Basicamente, o cliente precisa aprovar o pedido para que possamos faturar.
- Legal. O que vocês repassam para o cliente para que ele aprove o pedido?
- Basicamente só o valor total do mesmo.
- Ok. E o total do pedido eu presumo que seja a soma dos totais dos seus itens, certo?
- Correto.
Primeiro requisito implementável: o total do pedido deve ser igual a soma dos totais dos itens da ordem (tá, eu sei, exemplo manjado, mas é muito fácil de entender, pelo menos).
@Test
public void testaTotalPedido() {
Pedido pedido = new Pedido(new Cliente("Marcelo"));
pedido.addItem(new ItemPedido("parafuso",5,0.1));
pedido.addItem(new ItemPedido("mancal",3,5.0));
assertEquals(pedido.getTotal(),15.5);
--- Cliente.java ---
public class Cliente {
private String nome;
public Cliente(String nome) {
this.nome = nome;
}
//getters...
}
--- Pedido.java ---
public class Pedido {
private final Cliente cliente;
private Set
public Pedido(Cliente cliente) {
this.cliente = cliente;
this.items = new HashSet
}
public void addItem(ItemPedido item) {
this.items.add(item);
}
public double getTotal() {
Iterator
double result = 0.0;
while (itItens.hasNext()) {
result += itItens.next().getValorTotal();
}
return result;
}
}
--- ItemPedido.java ---
public class ItemPedido {
private String descricao;
private double valorUnitario;
private int quantidade;
public ItemPedido(String descricao, int quantidade, double valorUnitario) {
this.descricao = descricao;
this.quantidade = quantidade;
this.valorUnitario = valorUnitario;
}
public double getTotal() {
return this.valorUnitario * this.quantidade;
}
}
O exemplo é ridículo, eu sei. Mas o que eu quis mostrar aqui é que o que foi criado até agora foram CLASSES DE DOMÍNIO, ou seja, o que realmente interessa. Não tem DAO, não tem View, não tem IO, nem outra porquera qualquer por que isso é secundário e é o mais fácil de resolver. FOCO NO DOMÍNIO.
- Resolve primeiro o problema do cliente, pô. Sem frescura.
