Como testar com JUnit

Neste post, vou mostrar como é fácil usar a versão 4.8.1 do JUnit, que pode ser encontrada no site oficial. Além disso, pretendo mostrar como não ferir a Lei de Demeter em uma situação corriqueira, objetos com listas.

Quando estão trabalhando com listas, algumas pessoas tendem em apenas expor o atributo através de um getter. É mais simples.

O problema não é meu - Parte II

Bem, vamos ao que interessa: Quando fazer as alterações não contempladas em um chamado? Como fazer de forma segura? Como ser eficiente para não afetar as metas?

Quero assegurar, mais uma vez, que o descrito nesse artigo ou em qualquer outro neste blog, expressa apenas a minha opinião, não a do meu empregador ou clientes.

O problema não é meu - Parte I

Devo desculpas aos amigos que acompanham este singelo espaço, por não escrever nenhum artigo há muito tempo. Infelizmente isso deve ser comum neste próximo ano. Estou em uma equipe que atua com BPM e estamos implantando este conceito em uma das maiores empresas do Brasil.

Já vinha estudando sobre gerenciamento de processos desde fevereiro deste ano, época da minha primeira passagem pela equipe. Tive uma rápida passagem por ETL e, há dois meses, estou de volta ao BPM. Aprendi muitas coisas neste período, principalmente a lidar com a diversidade de profissionais. E é justamente esse o ponto central desta pequena série. Tenho trabalhado com o ALBPM e com um Java que não é Java, mas é Java. Sim, a coisa é meio confusa. Entretanto, existem aplicações puramente Java que auxiliam o sistema como um todo, como as consultas.

Qualidade na prática - I

Vou iniciar a série prática com um exemplo que está presente na vida de 10 entre 10 desenvolvedores: as estruturas condicionais. Esse exemplo é sobre a estrutura IF. Os códigos estão na linguagem Java.

Vemos if's o tempo todo na nossa vida. Atravessaremos a rua, se o sinal estiver fechado ou não vier carro. O mais interessante é que, normalmente, este teste, está vinculado à uma ação. Sendo assim, definiremos estratégias para as tomadas de decisão. Entretanto, não falarei em termos de OO ainda. Vou mostrar como, proceduralmente, é fácil programar uma estrutura IF mais clara, facilitando a sua vida e de quem vai manter o código.

Os IFs do nosso dia-a-dia estão encapsulados. Quando chegamos na beira de uma rua, não pensamos ou falamos em voz alta: Só vou atravessar quando o sinal fechar ou não vier carros.

Segue um exemplo clássico, ao qual todos os membros da equipe devem ter atenção, e não é nenhuma obra de gênio.

O código inicial, com o desenvolvedor pensando apenas na correção e na robustez:



Abaixo, modularizei as lógicas de teste, melhorando a clareza, facilitando a manutenção. Notem que os comentários desapareceram, pois o código é auto explicativo:


Na próxima fase, eliminei os números mágicos:


A melhora na legibilidade é clara. Possibilitamos, também, o reúso, pois, se algum outro algorítmo precisar testar status, não precisaremos reescrever a lógica. Dessa forma, evitamos a duplicação de código, que muito mal faz para a saúde do desenvolvedor.

Mesmo sem nos preocuparmos com a OO, percebemos, claramente, os benefícios de um código bem escrito. Para desenvolver dessa forma não precisamos ser nenhum doutor de Havard ou consumir muitas horas do projeto.

Esta refatoração mostra a questão do ganho de habilidade com a prática. Será muito difícil codificarmos como na fase 1 novamente, já que este tipo de boa prática é muito fácil implementar de primeira. O que está relacionado ao uso insistente do primeiro código pelos desenvolvedores é a falta da inquietação com os maus cheiros que afloram de sua obra.

Concluindo, esta refatoração não exige horas a mais de projeto, somente vontade do desenvolvedor em sempre codificar melhor.

O livro Refactoring: Improving the Design of Existing Code do Martin Fowler, contribui sobremaneira para este tipo de pensamento no momento de codificar.

O impacto na implementação

A implementação é a transformação efetiva dos requisitos em código. Assim, esta fase decidirá a sua vida no futuro. Se precisará de dias (noites, fins de semana) para implementar/modificar um requisito. Se a sua vida será um inferno e o desenvolvimento um castigo, ou se você terá uma vida normal e o desenvolvimento será um prazer. Investir algumas horas procurando a melhor solução, pode fazer toda diferença na sua qualidade de vida. Este artigo desenvolve muito bem este assunto.

Acredito que mesmo os profissionais gurus da qualidade de código, identifiquem, vez ou outra, em suas soluções, algoritmos que podem ser melhorados. Dessa forma, a refatoração deve ser companheira de todo desenvolvedor que busque a excelência de suas soluções. O livro Refactoring: Improving the Design of Existing Code será referenciado constantemente nesse blog.

Quanto mais você se preocupa com a qualidade, mais natural ela se torna. Se produzimos um código e concluimos que é de baixa qualidade, devemos tentar a refatoração. O mesmo se dá quando estamos trabalhando com código legado. Este feeling é chamado de "detecção de mau cheiro" por Fowler. Da próxima vez que nos depararmos com a necessidade de um(a) algoritmo/arquitetura parecido(a), lembraremos da melhor prática que foi aplicada anteriormente e o código já terá uma certa qualidade de primeira. Depois de certo tempo, nem acreditaremos que desenvolvíamos aquele algoritmo daquela forma.

A solução refatorada pode ainda não ser uma excelência em qualidade, mas um passo já foi dado. Da próxima vez, refinaremos um pouco mais. Dessa forma, nossas soluções tendem a qualidade total. É uma busca infinita pela excelência. Este é um dos pontos que torna a nossa profissão tão interessante, na minha opnião.

Não ficarei apenas discutindo os princípios da qualidade, o porque ou outras teorias. Será criada uma série Qualidade na Prática, onde vou mostrar exemplos, no estilo passo a passo, de refatorações que fiz em códigos meus e de outros desenvolvedores.

Existe um tópico no GUJ, do Daniel Destro, bem interessante, pois mostra o que não se deve fazer em uma solução Java. Este tópico é mais antigo que o meu registro, é constantemente atualizado e é um dos campeões de visitas do fórum.

Sei que o dito "mundo perfeito" é uma utopia. Mas busca-lo deve ser uma atividade diária.