Para evitar o tédio, fixtures

Duas coisas aconteceriam se você fizesse testes apenas como ensinei no último post: tédio seria a primeira, porque você precisaria criar novas instâncias dos Modelos o tempo todo. A segunda seria a falta de instâncias de Modelos das tabelas que não fazem parte do teste (o que também geraria tédio, já que você precisaria criar cada uma dessas instâncias).

Para resolver isso, existem as fixtures.

Mas o que são fixtures, afinal?

São arquivos YML (Yet another Markup Language, não confundir com XML) que definem instâncias dos modelos. Os arquivos são criados quando você gera os modelos (exatamente como os testes de unidade), mas ficam "vazios", apenas com comentários ensinando a usá-los.

Criar instâncias de uma classe com uma fixture é fácil. Digamos que você queira criar uma instância que você acesse com "programador" (você verá como acessar fixtures mais tarde, então não se preocupe com isso, por enquanto). Tudo o que você precisaria fazer é abrir o arquivo pessoa.yml na pasta test/fixtures, apague tudo o que estiver no arquivo, e digite:

programador:
  id: 1
  nome: Yuri Albuquerque
  salario: 100.00
  data_nascimento: <%= Date.civil(1989, 11, 9) %>

Atente para a identação, ela deve ser dois espaços, e não TAB.

As fixtures são uma maneira bastante concisa de se armazenar dados de testes. Elas são intuitivas para quem vê, são carregadas sempre que os testes são inicializados, e não apresentam muitas dificuldades de acesso.

Porém têm algumas desvantagens. Elas tornam as suítes (conjuntos) de testes lentas; permitem dados inválidos; é complicado manter um grande número de dados em fixtures; e elas são frágeis, no sentido de que uma alteração numa fixture pode afetar o resultado dos seus testes (desvantagens tiradas do livro Programando Rails, "A Bíblia", de David H. Hansson).

Todavia, você pode evitar praticamente tudo com um certo cuidado. Para evitar lentidão, crie apenas fixtures estritamente necessárias (obviamente, isso também evita um grande número de dados). Para evitar dados inválidos, evitem escrever dados inválidos (afinal, você tem total controle sobre o que está numa fixture). Quanto à fragilidade, tome cuidado redobrado com todos os seus testes, o seria uma atitude boa mesmo que você não usasse fixtures.

Finalmente, explicando o código anterior. Boa parte é lógico e intuitivo. A primeira linha indica que toda a identação seguinte será armazenada numa instância "programador". Cada uma das linhas seguintes define um campo da instância.

Mas... o que quer dizer dizer aquele <%= Date.civil(1989, 11, 9) %> ali no meio? É algo bem simples, na verdade. Chama-se expressão. Quando você inicializar as fixtures (o que é feito automaticamente quando você inicia seus testes com rake), o Ruby se encarregará de substituir todo o código entre <%= %> pela string equivalente.

Nesse caso, <%= Date.civil(1989, 11, 9) %> vai ser lido como 1989-11-09.

Mas... por que escrever expressões, quando você pode inserir o dado que você quer?

Lembrem-se: a fixture não filtra dados inválidos. O uso de expressões é uma das muitas formas de evitar a inserção de dados inválidos. Além do quê, muitas vezes o uso de uma expressão é imprescindível, como verá a seguir.

Você deve estar pensando agora "se o Ruby reconhece o código dentro da expressão, eu posso usá-la para fazer um loop e criar várias instâncias de uma vez?". Não. Não pode. A expressão SEMPRE vai ser convertida em string, então tentar executar um loop vai resultar em nil. "Que pena", você deve estar pensando. "Eu gostaria muito de poder gerar dados automaticamente, em vez de digitá-los à exaustão".

E você pode. Só não vai usar expressões para isso, e sim scriplets.

Scriplets são muito parecidos com expressões, inclusive na sintaxe. A principal diferença é que eles NÃO são convertidos em strings, então você pode usá-los para gerenciar códigos e variáveis diretamente no arquivo, e inclusive criar loops.

Um scriplet é definido entre <% %>. Sim, é só tirar o sinal de igual. Vamos dizer que você queira definir cinco fixtures quaisquer de Pessoa. Você pode muito bem, em vez de digitar de uma por uma, fazer isso:

<% for i in (1..5) %>
pessoa_<%= i %>:
  id: <%= i %>
  nome: pes_<%= i %>
  salario: <%= i * 100 %>
  data_nascimento: <%= Date.civil(1980, i, i) %>
<% end %>

Como tudo no Ruby, há mais de uma maneira de escrever a mesma coisa. Minha forma preferida é substituir <% for i in (1..5) %> por <% 1.upto 5 do |i| %>, mas isso não vem ao caso. O que importa é como o Ruby vai enxergar sua fixture depois do processamento, e será assim:

pessoa_1:
  id: 1
  nome: pes_1
  salario: 100
  data_nascimento: 1980-01-01

pessoa_2:
  id: 2
  nome: pes_2
  salario: 200
  data_nascimento: 1980-02-02

pessoa_3:
  id: 3
  nome: pes_3
  salario: 300
  data_nascimento: 1980-03-03

pessoa_4:
  id: 4
  nome: pes_4
  salario: 400
  data_nascimento: 1980-04-04

pessoa_5:
  id: 5
  nome: pes_5
  salario: 500
  data_nascimento: 1980-05-05

Claro que a quantidade de fixtures vai contra a ideia de fazer apenas a quantidade necessária, mas é só um exemplo didático, então não há problemas.

E mais uma dica: lembre-se sempre das expressões e dos scriplets. Eles vão ser SEMPRE necessários, mesmo quando você não estiver fazendo testes