Marcos Sousa’s Blog

Depois de algumas versões Beta e 2 candidatas a realease, o seam disponibilizou esta semana a versão 2.1 estável. Esta versão trás uma série de novos recursos, alguns deles muito interessantes como o módulo de gerenciamento de autenticação usando o modelo ACL de permissões e suporte a Wicket.

Para quem gera documentos excel, tenho uma boa notícia, agora facilmente será possível criar documentos XLS utilizando um módulo específico do Seam para isto. Integrado ao JExcelAPI, o módulo possibilita gerar planilhas com um simples documento XHTML de maneira bem semelhante ao geração de PDF, que já abordada anteriomente.

A criação de URL User Friendly agora tem suporte buit in ao URL Rewriter sem contar o suporte a JAX-RS através do suporte ao RESTeasy. A parte Core sofreu várias melhorias com melhor suporte a Cache e principalmente o suporte a chamadas simultâneas dentro de um mesmo escopo de conversação.

A melhoria da performance e escalabilidade terão destaque para o próximo release. A documentação para clustering está sendo preparada para usar juntamente com o Jboss Clustering. Há também rumores que nos próximos realeases o suporte ao OpenID já estará disponível.

Observando o comportamento em vários projetos, pude perceber que grande parte das pessoas não dão muito valor aos testes, e quando valorizam atribui a responsabilidade de testar a outras pessoas. As coisas ainda ficam piores quando chega a pequenas empresas. Pergunte ao dono da padaria que você toma café todos os dias, se eles testaram alguma funcionalidade do software que eles tem antes de colocar em produção? Se a versão tiver algum problema e corromper os dados, a culpa sem sombra de dúvidas será do time de desenvolvimento.

O problema começa no modo como as pessoas projetam o software, dentro de um processo Waterfall, onde cliente não é parte do processo. Neste contexto, o cliente diz o que deseja e depois de 9 meses ele tem um resultado: um software produzido nas “coxas”.

Mesmo em projetos onde existem práticas de testes, muitos deles ainda são ineficientes. O usuário apenas valida as “telinhas” do sistema, e muito pouco em termos funcionalidades. Infelizmente, poucos destes usuários testam o comportamento de entradas de dados inválidos, por exemplo, um campo de CPF aceitar “-1″ como valor, ou um espaço em branco ser um conteúdo válido para um campo obrigatório. Como resultado, o sistema chega a produção, dados inconsistentes são inseridos e a culpa é do desenvolvedor.

Testes unitários é algo que muitos desenvolvedores ainda acham inútil, quando fala em integração contínua, aí acham exagero. Quer um exemplo, pergunte à um programador PHP se ele faz teste unitários. “Faço apenas sites, não sistemas, não preciso disso”, nem fazem idéia de que existe o PHPUnit para este propósito. Mesmo dentro de um obsoleto modelo cascata, cheio de casos de usos, porque não criar testes unitários pelo menos para validar os fluxos principais e alternativos? Pelo menos o fundamental pode ser controlado por um sistema de integração contínua.

Meu objetivo não é falar que práticas, como TDD, são perfeitas. O que eu quero chamar a atenção é importância que o teste tem dentro de um processo de desenvolvimento de software. Aparentemente, gastar algum tempo a mais fazendo testes, pode ser mais eficaz do que ter que corrigir uma falha que foi para produção por pura falta de atenção. Testar não é fácil e rápido, porém corrigir bugs pode ser mais demorado ainda.