Adicionado o .gitignore
Teste de integração de login arrumado.

Para o usuário fazer login, ele deve ter *todas as informações corretas* para
isso. Do jeito que estava, você estava enviando uma senha "123asda" como se o
usuário tivesse preenchido ela no formulário e clicado no botão "Autenticar".

Se você olhar na factory, a senha está como "123asda", mas essa é a *senha
gravada no banco*, é a hash, não é a senha decriptada que está sendo enviada
acima. Então, *nunca* o usuário iria conseguir fazer login com esse teste.

Existem duas opções nesse caso:

1. Alterar a factory para utilizar um atributo dinâmico, como por exemplo

code { User.encrypt_code("123asda") }

onde isso geraria a hash correta no banco.

2. Do jeito que eu fiz, que deixa explícito que a senha do usuário é aquela
mesma que ele tenta o login. Para isso, atualizei a senha "texto puro" (que gera
a hash gravada no banco) *antes* de tentar fazer a autenticação. Aí passou.
de tentar fazer o login.
Simplificado o login.

Ainda não entendi porque você fez dois models, User e Admin, sendo que o próprio
user tem um atributo de admin. Do jeito que está, duplica o código e ainda tem
que fazer aquele tipo de coisa no controller de login, identificando o tipo do
usuário pelo modelo e não por uma categorização.
Corrigidas as factories.

Aqui eu achei uma situação estranha: o usuário normal e o admin ambos tinham o
mesmo email! Se eles logarem, como fazer uma diferenciação consistente entre
ambos? De qualquer forma, alterei para terem emails distintos, mas seria
interessante ter uma forma de validar isso.

Nos journals, estava fixo o id da adoption, mas tem que ficar a referência.

Nas adoções, também estava fixo o id da teoria e do usuário. O do usuário é mais
chato pois se você criar sempre um usuário, vai dar de cara com a validação do
mesmo email. O pessoal da FactoryGirl parece ignorar todo tipo de patch para
criar um objeto do tipo singleton, então utilizei um trait para essa finalidade.
Tentei reduzir a duplicação de código, fazendo Admin herdar de User.

Porém em User teve que ser criado o atributo status que Admin tinha.
O que estava sendo testado era o id do User, não da Theory!

Não sei como você estava dando sorte com isso (ou eu que bebi, sei lá), mas se
você reparar, estava testando tanto o adopt como o abandon utilizando o id do
User, e não da Theory! Devia estar coincidindo dos ids serem os mesmos, e estava
passando, mas muita, muita atenção nisso, se o seu teste estiver errado, babau,
perde a função.
Ignorado o atributo admin quando criando um novo.
Pegando a Adoption direto do Journal criado.
Presence, blank e nil.

Se você usa presence: true, não precisa de allow_blank nem allow_nil.

Se você usa o format, aí sim você tem que especificar os dois, se puder ser
vazio.

Se o atributo puder ser nulo, não é necessário especificar que ele pode ser
branco ou nulo, é só omitir.
DRY nos métodos logged? e admin?

Aqui você pode ver um problema de ficar repetindo eles para todo lado ao invés
de colocar no application_controller: o logged? de Category era diferente dos
outros! Ao invés de redirecionar para "/entrar", estava redirecionando para "/".
ou seja, era um comportamento diferente.
Você não precisa testar true e false com ==.
Métodos para refatorar testes de tested, adoção e abandono por administrador.
Melhor um método para indicar o que é uma sessão de administrador.

Senão toda vez que você (ou outro desenvolvedor que for mexer no sistema, tipo,
eu) quiser testar vai ter que lembrar que na hash de sessão tem que estar com o
valor 2 na chave :kind.
Não precisamos mais do :tested aqui.
Método no modelo para testar se Theory já foi adotada.
Atualizado o schema com o campo de status do User
conflits]