Quando comecei a usa-lo no meu projeto, logo percebi que usar em inglês não seria legal, pois o projeto só fazia sentido no Brasil e portanto o interessante era escrever os cenários em português. A partir desse momento, comecei a escrever algumas classes pra fornecer esse suporte. Felizmente, as classes Scenario e Steps permitem fácil extensão para resolver esse problema. Após as modificações necessárias, o arquivo de cenário passou a se chamar nome.cenario e o texto no arquivo ficou da seguinte forma:

Como um Bom testador
Eu quero testar todo meu sistema
Para garantir a qualidade

Cenário: Nome em português do Brasil

Dado que eu quero rodar o Jbehave em português do Brasil
Quando eu usar o meu idioma
E estiver testando
Então tudo deve funcionar
E eu sou feliz

Feito isso, achei legal disponibilizar uma biblioteca para que outros desenvolvedores que precisem usar o JBehave no nosso idioma possam faze-lo de forma trivial. Nesse momento nasceu o projeto jbehave-br, extraido desse projeto e disponibilizado no GitHub aqui. O projeto é muito simples e pequeno, com o objetivo de resolver especificamente esse problema e nada mais.

[UPDATE] O Jbehave agora suporta internacionalização e refatorei essa biblioteca para se aproveitar disso. Está totalmente compatível com a versão 2.5[/UPDATE]

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Essas situações são muito frequentes, principalmente a primeira, com códigos fedorentos. Por isso, eu adoto uma postura: Sempre assino meus códigos.

O que seria assinar o código? Bem, assinar o código é aquela simples documentação que vem logo acima do arquivo, como por exemplo em Java, usando o famoso javadoc:

package xpto;
import x;
/**
* @author Emerson Macedo
*/
public class Abc {
// ...
}

Assinar o código pode parecer meio arrogante mas o objetivo não é esse. O propósito de assinar o código e se expor. Quando você assina alguma coisa, explicitamente está colocando a sua autoria naquilo, ficando sujeito tanto a críticas, quanto a elogios.

Quando algum pintor faz um quadro, ele sempre vem assinado em alguma parte. Dificilmente o autor dessa obra de arte vai terminar esse quadro antes que ele tenha certeza que está com ótima qualidade (pelo menos na visão dele).

E no que isso implica? Isso implica que você (1) vai pensar 2 vezes antes de colocar aquela habitual gambiarra no seu código, (2) vai pensar bem antes de concluir alguma coisa sem devidos testes automatizados e (3) vai ser muito mais responsável com o código que você está desenvolvendo.

Conclusão

Como qualquer desenvolvedor, já desenvolvi códigos ruins em diversos projetos pelos quais passei. Aquele que nunca desenvolveu código fedorento que atire a primeira pedra. Hoje em dia, não desprezo a qualidade daquilo que desenvolvo. Acredito muito que quando assinamos nossos códigos e nos damos conta que outro desenvolvedor/programador irá utiliza-lo futuramente, isso gera um maior cuidado com a qualidade.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Muitas vezes parei pra explicar pra vários colegas de trabalho sobre a importância do assunto, fiz pair-programmming pra ensinar como se faz, em fim, investi muito tempo pra ajudar diversas pessoas com isso. Por incrível que pareça, tem muiiiiiita gente que ainda não entendeu muito bem. Portanto, resolvi classificar a relação entre o desenvolvedor e os testes automatizados em 5 níveis.

São eles:

1. Ignorante: Esse é o nível no qual o desenvolvedor não sabe direito o que são testes automatizados ou sequer ouviu falar sobre o assunto (acredite, ainda tem gente assim em pleno 2009).
2. Indiferente: Nesse nível, o desenvolvedor já sabe o que é, mas acha que essa prática/tecnica não serve pra nada. Apenas toma tempo e atrasa a entrega do produto que está sendo desenvolvido. A sensação dele é que sem os testes a entrega seria mais rápida (e a quantidade de bugs tb vão aparecer mais rápido).
3. Prequiçoso: Nesse nível eu encontro muita gente. É nesse nível onde a ficha caiu mas o camarada não toma coragem pra aprender a fazer os testes automatizados. Ainda existe o medo de perder muito tempo com essa prática e a preguiça impera, impedindo o progresso.
4. Decidido: Esse pra mim é o nível mais importante. É nessa hora que o desenvolvedor se dá conta que não dá mais pra desenvolver software sem testes automatizados. É nessa hora que o cara pensa: “como eu pude desenvolver sem testes até hoje?”. É nesse momento que inicia-se o aprendizado.
5. Profissional: Nesse nível, o desenvolvedor já não se sente mais confortável desenvolvendo sem testes automatizados. Desenvolver sem testes o incomoda profundamente. Nesse momento o mesmo está maduro quanto a importância dos testes e a aplicação na prática. O mesmo começa a se tornar um evangelista para os demais desenvolvedores e sempre que pode, fala sobre o assunto. Nesse momento o desenvolvedor pode realmente dizer que é um profissional, pois hoje em dia não se admite mais desenvolver sem ter testes automatizados que garantam qualidade daquilo que se desenvolve.

Em qual nível você está?

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

O Artigo fala um pouco sobre erros comuns de times ágeis. Isso inclui não somente o time, mas P.Os, Scrum Masters e todos os demais envolvidos. Vale a pena conferir.

Os demais artigos também são de excelente qualidade e a leitura dos mesmos é extremamente recomendada.

Meus sinceros agradecimentos ao Manoel Pimentel e Felipe Rogrigues.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.