Testes unitários – you’re doing it wrong

14.maio.2009
Se você:
– Precisa de um método public static void Main(String[] args) para executar seus testes
– Depende de uma ordem pré-determinada para executá-los
– Caso um teste falhe, todos falham na seqüência
– Dependa de um banco de dados, de uma conexão ou de qualquer recurso externo para executar o teste
– Precise rodar os testes na mão toda vez que quiser saber se estão passando
– Escreve testes sem assert com freqüência

Sinto dizer, mas você não está usando testes unitários.

Update: Estou amadurecendo melhor a idéia, mas relendo isso aqui, e conversando com alguns desenvolvedores, fiquei pensando: “OK, você está fazendo errado. Então como é o certo? Por que está errado?”. Fiquei em dívida com vocês. Mas pretendo publicar algo mais decente sobre isso em breve.

Anúncios

O que não é Scrum

13.maio.2009

dilbert-agile-programming

Departamento de sistemas da matriz adotou Scrum como metodologia de desenvolvimento. Bacana, não?

Não.

Primeiro ponto: Scrum é um framework de gerenciamento de projetos, e não de engenharia. Obrigatoriamente você vai precisar de alguma técnica complementar se quiser que seu desenvolvimento de sistemas (no caso) esteja dentro do que se considera aceitável. Os responsáveis pela adoção acreditam realmente que apenas o Scrum vai salvá-los da danação eterna.

Segundo: usar Post-its, quadros brancos, burndown charts e mimimitings não significa que você esteja usando Scrum. Daily Meetings semanais e Stand-up Meetings sentados, com três horas de duração também não tem nada a ver com Scrum.

Terceiro: Aposto um dedo da mão direita como um “Scrum” aplicado dessa forma vai afundar o projeto, ou pelo menos vai gerar um produto de péssima qualidade, caro de se manter e muito, mas muito estressante de se trabalhar.

Aposto outro dedo da mesma mão como o Scrum vai levar a culpa e vai ser banido a pontapés da empresa. Com o risco de alguém olhar para trás e se transformar numa estátua de sal.

Pedir a benção do Papa para ‘implantar Scrum’ dentro da empresa não soa exatamente ágil. O que a empresa teoricamente espera é software que funciona, com qualidade, dentro de prazo e custo estimados. Se você tem que beijar a mão do bispo para conseguir trabalhar direito, a agilidade definitivamente não faz parte do DNA da empresa.

E finalmente, imprimir “Scrum & XP from the Trenches” e ler passo a passo antes de tomar uma decisão só mostra o quão despreparadas estão as pessoas envolvidas. Por maior que seja a boa vontade, não vai rolar.

Scrum é flexível, e muito. Mas mudar os alicerces do framework é como ser católico sem acreditar em Deus.

Como bem escreveu Rodrigo Panachi, “agilidade não é metodologia, é atitude”.

Update: Recomendo a leitura do artigo do Rodrigo Yoshima.


Primeiros passos em Rails

16.fevereiro.2009
Ambiente devidamente configurado, fui eu meter as caras no Rails, framework para agilizar e divertir (???) o desenvolvedor, segundo informado no próprio site.

Algumas coisas me empurraram para o Rails, na ordem:

– Curiosidade: acredite, um programador sem curiosidade não é nada além de um repetidor de tarefas.
– Custo: desenvolvendo em Grails eu teria que contratar uma JVM dedicada para hospedar minha aplicação. Isso gerou um custo que deixou o cliente insatisfeito. Como quem manda é ele, fui obrigado a buscar uma solução mais econômica.
– Compatibilidade: Boa parte da aplicação já estava feita em Grails, então eu precisaria aproveitar o máximo possível. Devido ao fato do Grails ter sido criado usando o Rails como base, a migração teoricamente seria menos traumática.
– Produtividade: Esse é o ponto chave do Rails. Em termos de custo de hospedagem, pode ser comparado ao PHP, mas com certeza é uma ferramenta que provê muito mais recursos do que o dinossauro da Zend. Por exemplo, eu posso criar uma tela de cadastro no Rails utilizando poucas linhas de código, enquanto no PHP não existe nenhum suporte nativo a isso, apesar de ferramentas como PHPScaffold.

Tive alguns problemas chatos tentando utilizar o ActiveScaffold, mas esse é mais um projeto que sofre da clássica doença do “fiz, mas não testei”. Não funcionou de jeito nenhum com o Rails 2.2.2 que estou utilizando. Instalei o Streamlined e, por enquanto, tudo está caminhando tranquilamente.


Tipo byte em Java

15.janeiro.2009
O tipo byte, na linguagem Java, tem comprimento de oito bits e armazena valores inteiros entre -127 e 128.

No post anterior eu citei o caso do método que recebia 255 e retornava -1. Isso acontece por que qualquer valor acima de 128 e menor que 256 (o máximo passa a ser representado usando oito bits) passa a ser representado como um valor negativo.

Exemplo:

byte exemplo1 = 127; // por ser menor que 128, não precisa de cast
byte exemplo2 = (byte) 255; // por ser maior que 128, o cast é necessário
byte exemplo3 = (byte) 254; // idem acima

println(exemplo1); // mostra 127
println(exemplo2); // mostra -1
println(exemplo3); // mostra -2

Qualquer valor menor que -127 e maior que 128 exise um cast (ou typecast, ou ‘coerção de dados’) para ser atribuído.

Cast é quando você força um valor de um tipo a ser de outro tipo. No caso ilustrado acima, valores menores que -127 e maiores que 128 são considerados como sendo do tipo int, exigindo a conversão antes da atribuição.