Agora aprofundarei mais no assunto Unit Tests. Na verdade, o uso desse termo no Rails é incorreto, porque "testes de unidade" fazem testes de mecanismos e/ou objetos de forma independente do restante do sistema.
Em outras palavras, quando você faz um teste de unidade, testa apenas aquela unidade do sistema. Caso você necessite de interação com outros objetos nesse tipo de teste, você recorre a objetos mock, que seriam simulações ou simplificações dos objetos reais.
Esse isolamento é necessário para manter as interfaces do objeto simples e o código limpo, com um design simplificado.
No Rails, por outro lado, esse isolamento não ocorre. Por quê? Não tenho certeza. Mas, na prática, o funcionamento dos testes de unidade no Rails não diferem tanto quanto um teste de unidade comum, já que você provavelmente não vai chamar nenhuma função de um modelo diferente do testado. A diferença acaba sendo que você não se utiliza de mocks (o que pode até ser algo bom).
No Rails, os testes de unidade testam os modelos (lembra deles?). Vamos criar um modelo para fazer um teste simples do Rails.
Primeiro, abra o console (ou prompt) e vá ao diretório raíz do seu projeto. Depois, digite:
Explicando: a pasta script contém várias utilidades para ajudá-lo na criação da sua aplicação. O script "generate" gera o que você mandar ele gerar, seja um modelo, um controlador, migração ou scaffold. Explicarei tudo isso em posts futuros.
O parâmetro model serve para especificar que o que você está gerando é um modelo. Pessoa diz qual é o nome do modelo. Os outros definem os atributos do mesmo (e da respectiva tabela).
Agora, digite
Quando você gera um modelo, também gera uma migração (na pasta db/migrate) respectiva àquele modelo. A migração gera a tabela no banco de dados, com o comando acima. Bem mais simples que digitar todo o SQL, não?
Junto com o modelo gerado, também é criado um teste de unidade na pasta test/unit. Abra-o. Ele já possui uma asserção, que sempre retornará verdadeiro. Digite
No console e você verá um sinal de sucesso. Não é o que queremos, por enquanto.
Abra o teste (em test/unit/pessoa_test.rb). Apague as linhas
Agora vamos começar a testar, mesmo. Por enquanto, não temos nenhuma funcionalidade especial em mente, então vamos começar com uma interessante. O usuário só pode se cadastrar se ele digita um nome.
Onde havia o código anterior, digite.
Esse código é bem simples. Se vocês não sabem o que é "def", voltem ao Ruby antes de estudar Rails, é simplesmente a definição de um método. Todos os métodos da classe que começam com "test" são o teste, em si. Todas as asserções dentro do teste serão analizadas, e caso todas sejam válidas, o teste contará como um sucesso.
As três linhas seguintes são óbvias: estamos declarando uma pessoa e definindo um salário e uma data de nascimento para ela.
A linha "assert !pessoa.save" é a chave do teste. Assert é uma asserção (que eu tanto falei há algumas linhas e ainda não expliquei). Asserções validam o que há dentro delas. Se realmente for algo válido, a asserção retorna um sucesso. Senão, ela pára o teste e avisa que houve uma falha.
A asserção mais simples é "assert", que verifica se o que está dentro dela é true.
O que nos leva à questão: o método pessoa.save retorna um boolean?
A resposta é sim. Sempre que o Rails tenta salvar um registro no banco de dados, ele retorna true caso ele tenha conseguido e false caso não tenha conseguido. Nesse caso, nós queremos que retorne false, porque não queremos que ele consiga salvar o registro, já que o nome da pessoa não foi definido. Por isso o "!" antes de pessoa.save, ele simboliza "não" em muitas linguagens de programação, inclusive Ruby.
Vá no console e digite rake novamente. Você vai ver o teste falhar.
"Tudo isso para um teste falho? Mas não queríamos fazer um programa, afinal de contas?"
Novamente, estamos testando ANTES de fazer o código que vai validar o teste. Isso é o que chamamos de Test-Driven Development, ou Desenvolvimento Orientado a Testes. Sempre que você for programar, primeiro faz os testes automatizados, roda-os, vê falharem, e faz os códigos o mais simples possíveis para passarem nos testes.
Dessa forma, você terá um sistema simples, legível e com o mínimo de bugs.
Agora vamos fazer o teste retornar um sucesso.
Abra o arquivo app/models/pessoa.rb. Insira dentro da classe a linha
Essa linha é bem óbvia. É um validador, e vai verificar se o usuário lembrou de digitar seu próprio nome. Não se preocupe com isso, por enquanto, também vou explicar em posts futuros.
Rode o rake de novo e veja o teste retornar um sucesso. Parabéns! Você fez um teste de unidade!
No próximo post, explicarei fixtures e como elas podem melhorar seus testes.
Em outras palavras, quando você faz um teste de unidade, testa apenas aquela unidade do sistema. Caso você necessite de interação com outros objetos nesse tipo de teste, você recorre a objetos mock, que seriam simulações ou simplificações dos objetos reais.
Esse isolamento é necessário para manter as interfaces do objeto simples e o código limpo, com um design simplificado.
No Rails, por outro lado, esse isolamento não ocorre. Por quê? Não tenho certeza. Mas, na prática, o funcionamento dos testes de unidade no Rails não diferem tanto quanto um teste de unidade comum, já que você provavelmente não vai chamar nenhuma função de um modelo diferente do testado. A diferença acaba sendo que você não se utiliza de mocks (o que pode até ser algo bom).
No Rails, os testes de unidade testam os modelos (lembra deles?). Vamos criar um modelo para fazer um teste simples do Rails.
Primeiro, abra o console (ou prompt) e vá ao diretório raíz do seu projeto. Depois, digite:
ruby script/generate model Pessoa nome:string data_nascimento:date salario:decimal
Explicando: a pasta script contém várias utilidades para ajudá-lo na criação da sua aplicação. O script "generate" gera o que você mandar ele gerar, seja um modelo, um controlador, migração ou scaffold. Explicarei tudo isso em posts futuros.
O parâmetro model serve para especificar que o que você está gerando é um modelo. Pessoa diz qual é o nome do modelo. Os outros definem os atributos do mesmo (e da respectiva tabela).
Agora, digite
rake db:migrate
Quando você gera um modelo, também gera uma migração (na pasta db/migrate) respectiva àquele modelo. A migração gera a tabela no banco de dados, com o comando acima. Bem mais simples que digitar todo o SQL, não?
Junto com o modelo gerado, também é criado um teste de unidade na pasta test/unit. Abra-o. Ele já possui uma asserção, que sempre retornará verdadeiro. Digite
rake
No console e você verá um sinal de sucesso. Não é o que queremos, por enquanto.
Abra o teste (em test/unit/pessoa_test.rb). Apague as linhas
test "the truth" do assert true end
Agora vamos começar a testar, mesmo. Por enquanto, não temos nenhuma funcionalidade especial em mente, então vamos começar com uma interessante. O usuário só pode se cadastrar se ele digita um nome.
Onde havia o código anterior, digite.
def test_usuario_cadastrou_um_nome pessoa = Pessoa.new pessoa.salario = 1000.00 pessoa.data_nascimento = Date.civil(1989,11,9) assert !pessoa.save end
Esse código é bem simples. Se vocês não sabem o que é "def", voltem ao Ruby antes de estudar Rails, é simplesmente a definição de um método. Todos os métodos da classe que começam com "test" são o teste, em si. Todas as asserções dentro do teste serão analizadas, e caso todas sejam válidas, o teste contará como um sucesso.
As três linhas seguintes são óbvias: estamos declarando uma pessoa e definindo um salário e uma data de nascimento para ela.
A linha "assert !pessoa.save" é a chave do teste. Assert é uma asserção (que eu tanto falei há algumas linhas e ainda não expliquei). Asserções validam o que há dentro delas. Se realmente for algo válido, a asserção retorna um sucesso. Senão, ela pára o teste e avisa que houve uma falha.
A asserção mais simples é "assert", que verifica se o que está dentro dela é true.
O que nos leva à questão: o método pessoa.save retorna um boolean?
A resposta é sim. Sempre que o Rails tenta salvar um registro no banco de dados, ele retorna true caso ele tenha conseguido e false caso não tenha conseguido. Nesse caso, nós queremos que retorne false, porque não queremos que ele consiga salvar o registro, já que o nome da pessoa não foi definido. Por isso o "!" antes de pessoa.save, ele simboliza "não" em muitas linguagens de programação, inclusive Ruby.
Vá no console e digite rake novamente. Você vai ver o teste falhar.
"Tudo isso para um teste falho? Mas não queríamos fazer um programa, afinal de contas?"
Novamente, estamos testando ANTES de fazer o código que vai validar o teste. Isso é o que chamamos de Test-Driven Development, ou Desenvolvimento Orientado a Testes. Sempre que você for programar, primeiro faz os testes automatizados, roda-os, vê falharem, e faz os códigos o mais simples possíveis para passarem nos testes.
Dessa forma, você terá um sistema simples, legível e com o mínimo de bugs.
Agora vamos fazer o teste retornar um sucesso.
Abra o arquivo app/models/pessoa.rb. Insira dentro da classe a linha
validates_presence_of :nome
Essa linha é bem óbvia. É um validador, e vai verificar se o usuário lembrou de digitar seu próprio nome. Não se preocupe com isso, por enquanto, também vou explicar em posts futuros.
Rode o rake de novo e veja o teste retornar um sucesso. Parabéns! Você fez um teste de unidade!
No próximo post, explicarei fixtures e como elas podem melhorar seus testes.
Postagens
Nenhum comentário:
Postar um comentário