Galera estou lendo mais um livro, e vou passar para vocês um textículo do inicio do Rails 3 in Action.
Lendo o capitulo 1, ele deixou uma pergunta no ar: como você faz aplicações Rails sustentável?
A resposta é que você escreve testes automatizados para a aplicação como você desenvolve, e você escreve isso o tempo todo.
Ao escrever testes automatizados para a sua aplicação, você pode rapidamente assegurar que o aplicativo está funcionando como deveria. Se você não escrever testes, a sua alternativa seria a de verificar toda a aplicação manualmente, o que é demorado e propício a erros. Teste automatizado economiza uma tonelada de tempo, a longo prazo e leva a menos bugs. Os seres humanos cometem erros; programas (se codificado corretamente) não.
Teste e desenvolvimento orientado a comportamento
No mundo Ruby
uma enorme ênfase é colocada em teste, especificamente desenvolvimento orientado a testes (Test-driven
development - TDD) e desenvolvimento de comportamentos (Behavior-Driven Development - BDD).
Ao aprender técnicas de teste bem como agora, você tem um caminho sólido para se certificar que nada esta quebrado quando você começa a escrever sua primeira aplicação real Rails. Se você não testar, não há como dizer o que poderia dar errado seu código.
TDD é uma metodologia que consiste em escrever um caso de teste falho primeiro (geralmente usando uma testar ferramenta
como Test::Unit
), em seguida, escrever o código para fazer o teste passar e, finalmente, refatorar o código. Este
processo é comumente chamado de vermelho-verde-refatorar
( red-green-refactor
). As razões para desenvolver código desta
forma são duas. Primeiro, faz você considera como o código deve ser executado antes de ser usado por qualquer pessoa. Em
segundo lugar, crie um teste automatizado, você pode executar quantas vezes você quiser para garantir que o seu código ainda
está trabalhando como pretendido.
BDD é uma metodologia baseada em TDD. Você escreve um teste automatizado para verificar a interação entre as diferentes partes da base de código em vez de testar que cada parte funciona de forma independente.
As duas ferramentas são usadas para o BDD são (RSpec)[http://rspec.info/] e (Cucumber)[http://cukes.info/].
Test-Driven Development
Uma resposta enigmática mas verdadeira para a pergunta “Por que eu deveria testar?” é “porque você é humano.”. Os seres humanos - a grande maioria deste livro - comete erros. É uma de nossas favoritas maneiras de aprender. Porque os seres-humanos cometem erros, ter uma ferramenta para informar quando eles fazem um erro é útil, não é? Teste automatizado fornece uma rápida segurança para informar aos desenvolvedores quando eles cometem erros. Por eles, é claro, queremos dizer que você. Nós queremos que você faça poucos erros quanto possível. Queremos que salvar sua vida!
TDD e BDD também dar-lhe tempo para pensar nas suas decisões antes de escrever qualquer código. Escrevendo primeiro teste para a implementação, você é (ou, pelo menos, você deve ser) levado a pensar através da implementação: o código que você vai escrever depois do teste e como você vai fazer para o teste passar. Se você encontrar um teste difícil de escrever, então talvez a implementação pode ser melhorada. Infelizmente, não há nenhuma maneira clara de quantificar a dificuldade de escrever um teste e trabalhar com ele para além de consultar outras pessoas que estão familiarizadas com o processo.
Uma vez que o teste é implementado, você deve ir escrever algum código que o seu teste pode passar. Se você está trabalhando escrevendo o código primeiro e depois os testes para pegar um bug da implementação, é geralmente melhor repensar o teste e desfazer sua implementação.
Primeiro teste, código mais tarde.
Até mais amigos!