O Teste do Joel: 12 Passos para um Código Melhor

Nas minhas "andanças" pela internet acabei encontrando o Teste do Joel: 12 Passos para um Código Melhor e fiquei impressionado com o que li. 

Antes de falar do teste de Joel, preciso falar do próprio Joel é claro. Quem será esse tal Joel Spolky, então vamos lá: 

Joel Spolsky é um experiente programador, dono do Blog Joel On Software - um dos melhores (senão o melhor) blog sobre gerenciamento e desenvolvimento de software. Também é  o fundador da Fog Creek Software, uma pequena empresa de software na cidade de Nova York. Formou-se na Universidade de Yale, e trabalhou como programador e gerente na Microsoft, na Viacom e no Juno.

O legal do Teste do Joel é que ele consiste de 12 perguntas que deverão ser respondidas com SIM ou NÃO cada questão. Você não precisa realizar cálculos complicados para achar o resultado. Simplesmente atribua à sua equipe 1 ponto para cada "sim" respondido. 

Uma pontuação 12 é perfeita, 11 é tolerável, mas 10 ou menos indica que você tem sérios problemas. A verdade é que a maioria das empresas de software funcionam com uma pontuação 2 ou 3, e elas precisam de uma grande ajuda, porque companhias como a Microsoft funcionam com 12 pontos todo o tempo.

Então vamos lá às perguntas : 

1. Você usa controle de código?
2. Você pode compilar em somente um passo?
3. Você faz compilações diárias?
4. Você tem uma base de dados de bugs?
5. Você corrige os bugs antes de escrever código novo?
6. Você tem um cronograma atualizado?
7. Você tem uma especificação?
8. Os programadores tem condições de trabalho tranqüilas?
9. Você usa as melhores ferramentas que o dinheiro pode comprar?
10. Você tem testadores?
11. Novos candidatos escrevem código durante a entrevista?
12. Você faz testes de usabilidade de corredor?

Se você desejar poderá ler o artigo completo que serviu de base para este post e conhecer um pouco mais sobre cada um dos doze itens clique no link abaixo: 

http://brazil.joelonsoftware.com/Articles/TheJoelTest.html

Diante de tudo que li e do impacto que esse assunto causou em mim, nos proximos posts vou abordar assuntos correlatos aos itens do teste, e o primeiro deles será sobre controle de código, e sobre a ferramenta que uso para esta finalidade o GIT. 

Então ... temos um encontro marcado no próximo post.

Até lá. 

Desenvolvimento Orientado a Testes (TDD)

Test-Driven Development (TDD) ou Desenvolvimento Orientado a Testes é uma maneira diferente de escrever software. A diferença entre esta abordagem e a que você provavelmente está acostumado é que com TDD você vai evoluindo seu código aos poucos, conforme vai explorando o problema com o uso de testes automatizados escritos antes da solução sequer existir.
Algumas vantagens desta abordagem são:

• Incentiva a simplicidade: como a solução vai surgindo pouco a pouco, a tendência é que não se perca tempo com aquilo que não tem certeza que será usado em seguida. Expressões como “You Ain’t Gonna Need It (YAGNI)” e “Keep It Simple, Stupid (KISS)” são recorrentes quando se está programando orientado a testes.
  
• Aumenta a confiança no código: o sistema funciona de uma determinada maneira porque existem testes que foram utilizados durante sua criação e validam o que foi criado. E se ainda assim algum erro surgir, um novo teste é criado para reproduzí-lo e garantir que depois de solucionado ele não irá se repetir.
• Ajuda como documentação: os testes quando bem definidos são mais simples de ler que o código e, embora nem sempre sirvam como uma especificação para o usuário final, eles são uma fonte eficiente para entender o que o software faz. Além disso, esta documentação sempre estará atualizada com a aplicação.
• Facilita refactorings: quanto mais testes existem no sistema, maior é a segurança para fazer refactorings. Um erro causado por algum refactoring dificilmente vai passar desapercebido quando um ou mais testes falharem após a mudança.

Em TDD, um teste é um pedaço de software. A diferença entre teste e o código que está sendo produzido é que os testes têm 2 funções principais:

• De especificação, ou seja, definir uma regra que seu software deve obedecer
• De validação, ou seja, verificar que a regra é obedecida pelo software

Geralmente os testes são criados com algum framework do tipo xUnit (jUnit, nUnit Test::Unit etc) , mas também podem ser feitos num nível de funcionalidades (através de softwares como o FitNesse e Selenium) . Estas ferramentas servem basicamente para organizar os testes e facilitar na criação das verificações.
O processo de criação de programação orientado a testes é simples:

1. Escreva um teste que falhe. Pense no que o código deve fazer, descreva o contexto e defina quais são as verificações que precisam ser feitas. Não há um limite no número de testes, então quanto menos coisa cada teste descrever/verificar, melhor. No início também não é preciso se preocupar se a classe/método ainda não existe. Pense primeiro no teste e só depois que este estiver pronto crie o esqueleto de código necessário para que ele compile e falhe ao rodar.
2. Faça o teste passar. Agora chegou o ponto crucial: escreva o mínimo de código para que o teste passe. Controle o instinto natural do programador de tentar prever tudo que o código vai fazer e apenas faça o teste passar. Mesmo que tenha certeza que o código deve fazer mais coisas, fazer os testes passarem deve ser a única preocupação agora.
3. Refatore. Uma vez que o teste passou, verifique o que no código pode ser melhorado. Geralmente para um teste passar é preciso inserir duplicação através de constantes (técnica conhecida como Fake It). Agora é a hora de melhorar o código e remover as duplicações, lembrando que os testes devem continuar passando.

Estes 3 passos são repetidos até que não se consiga pensar em novos testes, o que indica que a funcionalidade está pronta.

Introdução ao TDD

Introdução ao Desenvolvimento Orientado a Testes (TDD)

Test-Driven Development (TDD) ou Desenvolvimento Orientado a Testes é uma maneira diferente de escrever software. A diferença entre esta abordagem e a que você provavelmente está acostumado é que com TDD você vai evoluindo seu código aos poucos, conforme vai explorando o problema com o uso de testes automatizados escritos antes da solução sequer existir.

Algumas vantagens desta abordagem são:

• * Incentiva a simplicidade: como a solução vai surgindo pouco a pouco, a tendência é que não se perca tempo com aquilo que não tem certeza que será usado em seguida. Expressões como “You Ain’t Gonna Need It (YAGNI)” e “Keep It Simple, Stupid (KISS)” são recorrentes quando se está programando orientado a testes.

• * Aumenta a confiança no código: o sistema funciona de uma determinada maneira porque existem testes que foram utilizados durante sua criação e validam o que foi criado. E se ainda assim algum erro surgir, um novo teste é criado para reproduzí-lo e garantir que depois de solucionado ele não irá se repetir.

• Ajuda como documentação: os testes quando bem definidos são mais simples de ler que o código e, embora nem sempre sirvam como uma especificação para o usuário final, eles são uma fonte eficiente para entender o que o software faz. Além disso, esta documentação sempre estará atualizada com a aplicação.

• Facilita refactorings: quanto mais testes existem no sistema, maior é a segurança para fazer refactorings. Um erro causado por algum refactoring dificilmente vai passar desapercebido quando um ou mais testes falharem após a mudança.

Em TDD, um teste é um pedaço de software. A diferença entre teste e o código que está sendo produzido é que os testes têm 2 funções principais:

• De especificação, ou seja, definir uma regra que seu software deve obedecer
• De validação, ou seja, verificar que a regra é obedecida pelo software

Geralmente os testes são criados com algum framework do tipo xUnit (jUnit, nUnit Test::Unit etc) , mas também podem ser feitos num nível de funcionalidades (através de softwares como o FitNesse e Selenium) . Estas ferramentas servem basicamente para organizar os testes e facilitar na criação das verificações.

O processo de criação de programação orientado a testes é simples:


1. Escreva um teste que falhe. Pense no que o código deve fazer, descreva o contexto e defina quais são as verificações que precisam ser feitas. Não há um limite no número de testes, então quanto menos coisa cada teste descrever/verificar, melhor. No início também não é preciso se preocupar se a classe/método ainda não existe. Pense primeiro no teste e só depois que este estiver pronto crie o esqueleto de código necessário para que ele compile e falhe ao rodar.

2. Faça o teste passar. Agora chegou o ponto crucial: escreva o mínimo de código para que o teste passe. Controle o instinto natural do programador de tentar prever tudo que o código vai fazer e apenas faça o teste passar. Mesmo que tenha certeza que o código deve fazer mais coisas, fazer os testes passarem deve ser a única preocupação agora.

3. Refatore. Uma vez que o teste passou, verifique o que no código pode ser melhorado. Geralmente para um teste passar é preciso inserir duplicação através de constantes (técnica conhecida como Fake It). Agora é a hora de melhorar o código e remover as duplicações, lembrando que os testes devem continuar passando.

Estes 3 passos são repetidos até que não se consiga pensar em novos testes, o que indica que a funcionalidade está pronta.

Fonte: http://dojofloripa.wordpress.com/2006/11/07/introducao-ao-desenvolvimento-orientado-a-testes/