RubyOnda Widget

August 31st, 2008 • IN PORTUGUESE

Bruno Miranda e Roberto Soares desenvolveram o RubyOnda, um website onde a própria comunidade pode contribuir com as últimas novidades sobre Ruby, Rails, e diversas outras tecnologias relacionadas.

Resolvi então colaborar um pouco, e desenvolvi um pequeno widget para o site. Com isso, agora é possível embedar as últimas notícias do RubyOnda no seu próprio site, basta que adicione a instrução abaixo:

< script src="http://rubyonda.com/widget-embedded.js" type="text/javascript">

Aparecerá assim na sua página:

A doce ilusão da alta cobertura em testes

August 28th, 2008 • 1 comment IN PORTUGUESE
Tags: tdd, tests

Há tempos atrás - quando eu trabalhava em grandes empresas de desenvolvimento de software - tinhamos em nosso workflow a prática de enviar nossos códigos para a equipe de QA realizar uma “extensa” bateria de testes. O código que passava nos testes era considerado de qualidade. Para os que não passavam, os programadores responsáveis eram alertados sobre a vulnerabilidade e tinham a missão de corrigí-los.

Lembro-me de participar de reuniões por motivos de falha encontrada no sistema após a entrada em produção. Os motivos de existir a falha eram estudados e na grande maioria das vezes, os testers acabavam sendo apontados como culpados por “não terem realizados testes suficientes”. Não me lembro de presenciar nada sobre “fazer testes ruins”, testes que em si, pouco testavam.

Após a expansão de TDD e dos frameworks que permitiram automatizar testes, medir a cobertura em testes de um determinado projeto foi uma evolução natural para quem utiliza testes automatizados. Diversas ferramentas, para diversas linguagens/plataformas, começaram a aparecer e a facilitar a monitoração deste indicador.

Porém, tenho visto em alguns projetos, que o índice de cobertura em testes tem sido encarado como um fim, ao invés de uma consequência. Valores para o índice de cobertura em testes tem sido estipulados no início do projeto, e o código - consequentemente a equipe - passa a ser encarada como “de qualidade”, caso mantenha o valor inicialmente estipulado.

Coincidentemente - ou não - alguns códigos de testes desses projetos não são tão bem escritos. Testam pouca coisa, ou absolutamente nada. Mas mesmo assim, a avaliação que o código recebe é de “auto grau de qualidade”, já que apresenta um elevado índice de cobertura em testes.

Resolvi então, escrever alguns exemplos para ilustrar esse post. No trecho abaixo, temos uma classe NumberUtil, que possui 2 métodos: 1) humanize_array - onde dado um array é retornado um outro array, porém com os números em forma de string - por extenso; 2) humanize - onde dado um número retorna a sua string - por extenso;

Olhando atentamente ao trecho acima, percebemos que existe um bug na linha 10. Isso faz com que dado o número 1, a string retornada seja “zero”.

Logo em seguida temos a sua classe de teste, chamada NumberUtilTest. Esperamos que essa classe possua uma boa cobertura em testes para que possa identificar o problema no trecho anterior.

Os dois métodos de NumberUtil são testados, a cobertura está boa, mas se executarmos os testes, nenhuma falha é apresentada. Exatamente o contrário do que imaginávamos, já que existe um bug na classe.

Isso acontece porque o método test_should_humanize_array não está bem escrito. Existe uma falha básica nele, que faz com que não identifique o bug. Ele deve esperar o valor “one” ao invés de “zero”, já que a primeira posição do array dado, tem valor 1.

Temos aqui um bom exemplo de alta cobertura em testes, mas com pouca qualidade em código, já que os testes não identificam um blug relativamente simples.

Outros tipos de falha em sistema, ocorrem por falta de implementação, falta de código. Isso é realmente mais difícil de ser capturado em testes automatizados. Vamos dar uma olhada no trecho a seguir:

Acima temos uma classe chamada Person, onde o programador esqueceu de retirar o comentário em uma validação para o atributo username. Isso faz com que, mesmo que nenhum valor para username seja informado, o objeto será salvo no banco de dados.

Vamos então verificar a sua classe de teste, chamada PersonTest.

Podemos verificar que o método test_should_create_person realiza um teste simples para a criação de um objeto Person, sem informar valor para o atributo username. Esse teste será executado com sucesso, mesmo que não seja desejável ter um objeto Person sem username preenchido.

Para isso, o mais interessante seria termos uma classe de teste um pouco mais robusta, conforme podemos visualizar abaixo:

Acima, testes são realizados para identificar falhas em código existente e em códigos não existente.

Com base nesses exemplos simples, podemos verificar que ter um alto índice em cobertura em testes não é razão para ter um código de qualidade escrito.

Fixar valores para esse indicador, não fará com que código de qualidade seja escrito. É preferencial que a escrita do bom código seja estimulada, assim como bons testes. Com isso, a alta cobertura em testes se apresentará como consequência e não como fim.

Tenho certeza que você já se deparou com código de teste mal escrito. Código que no final das contas, nada ou pouco testava. Caso tenha esse exemplo, mande para mim Envie para o meu e-mail (fmesquitacunha @ gmail), cole o código no Gist ou Pastie e me mande a URL. Ou ainda, faça um post no seu blog e link para cá. Quem sabe consigo fazer uma série sobre *Testes que nada testam*

Pilares para o sucesso de aplicações web

August 21st, 2008 • 1 comment IN PORTUGUESE
Tags: aplicacoes-web, produtos

Saber o que faz com que alguns produtos tenham mais sucesso que outros não é das tarefas mais simples. Na maioria das vezes, eles possuem basicamente as mesmas características, parecem oferecer as mesmas sensações, mas mesmo assim, uns são mais aceitos que outros.

São pequenos detalhes que passam despercebidos que fazem a diferença entre a receptividade de um produto ser maior entre os demais concorrentes.

Usuários quando questionados do porquê utilizam um produto e não outro, muitas vezes se encontram sem respostas para tal.

Posso me tomar como um exemplo. Utilizo aplicações web diariamente para gerenciar projetos, para me comunicar, para me organizar sobre o que será feito no meu dia-a-dia e para diversas outras coisas. E afirmo, existem excelentes opções de aplicações web para todas essas necessidades.

Elas não possuem muitas funcionalidades diferentes entre si. Basicamente fazem o que se propõem a fazer, variando apenas na maneira como fazem. Se é uma aplicação de gerência de projetos, controla tarefas, o que foi finalizado, o que está em andamento, etc. Todas fazem isso, variando apenas no como fazem.

Então o que leva a uma aplicação web ser tão mais divulgada do que outras do mesmo contexto? O que possuem de tão diferente dos seus concorrentes, que faz com que grande parte dos usuários as prefiram?

Jesse James Garrett escreveu um bom livro onde ele cita os elementos básicos da experiência do usuário. Ele menciona que o sucesso do produto não está só relacionado ao exterior, a como ele se apresenta. O autor defende que o processo de desenvolvimento de um produto é tão importante para o sucesso do mesmo, quanto o trabalho após o lançamento. O sucesso começa internamente, dentro da própria equipe que o constrói, que o elabora.

E para isso, ele defende que 9 disciplinas são de extrema importância para o desenvolvimento de aplicações web de sucesso.

1 - User Research: Projetar focado no seu usuário significa entender o que o seu usuário precisa, como pensa e se comporta. É importante também incorporar o que foi aprendido, sobre os usuários, dentro de todos os aspectos do seu processo.

2 - Site Strategy: Aqui é sobre definição de metas. Sobre a importância de possuir metas para sua aplicação web e sobre saber medir corretamente para que possa ser avaliado se a aplicação está cumprindo ou não com as metas pré-estabelecidas. Essa tarefa pode ser extremamente complicada.

3 - Technology Strategy: Aplicações web são tecnologicamente complexas. É importante estabelecer uma estratégia de tecnologia para sua aplicação, como: plataforma, padrões, tecnologias e como estas podem trabalhar em conjunto.

4 - Content Strategy: Conteúdo é a razão principal pelo que o usuário utiliza a sua aplicação web. Mas qual conteúdo oferecer para satisfazer as expectativas dos usuários? Quanto de conteúdo? E de que forma? Antes de você produzir conteúdo você precisa fazer esses questionamentos.

5 - Abstract Design: Arquitetura de Informação e Design de Interação são disciplinas importantes para expressar em um framework conceitual, a experiência final do usuário. Essas duas disciplinas já possuem seu valor reconhecido dentro de um processo de desenvolvimento de uma aplicação web.

6 - Technology Implementation: Desenvolver sistemas é uma tarefa dificil e envolve muito trabalho. Linguagens, protocolos, bancos de dados, testes, tudo precisa bem trabalhado. Quanto mais complexo for sua aplicação web, mais complexo será sua plataforma tecnológica.

7 - Content Production: Saber qual conteúdo você precisa não é o suficiente. Você precisa saber como produzi-lo.

8 - Concrete Design: Aqui você precisa determinar os detalhes específicos da interface, navegação, posições, disposição das informações e o design. Isso é fundamental para o produto final.

9 - Project Management: Esta disciplina é um elo de ligação para todas as outras. É importante manter em dia o gerenciamento de projeto para o desenvolvimento de sua aplicação web. Assim como manter atualizada técnicas de gestão.

Raramente dentro das empresas possuímos profissionais diferentes para cada disciplina, geralmente possuímos profissionais que ficam responsáveis por mais de uma disciplina. Não há problema nisso. Mas precisamos estar atentos se estamos aplicando essas disciplinas no desenvolvimento de nossas aplicações web.

Independente do tamanho da empresa, se é uma grande empresa de Internet ou uma startup, o mínimo de planejamento é necessário para que seja bem aproveitado o investimento para o desenvolvimento de um novo produto.