2016-04-13 1 views
0

Dans railstutorial.org, Listing 8.23:Y compris SessionsHelper dans RailsTutorial.org test_helper: pourquoi pas?

ENV['RAILS_ENV'] ||= 'test' 
. 
. 
. 
class ActiveSupport::TestCase 
    fixtures :all 

    # Returns true if a test user is logged in. 
    def is_logged_in? 
    !session[:user_id].nil? 
    end 
end 

propose de créer un procédé en double pour vérifier si l'utilisateur actuel est connecté (ayant déjà défini un tel procédé dans sessions_helper.rb) pour une utilisation dans les tests. Cependant, je me demandais pourquoi l'auteur a choisi de le faire en premier lieu. Il explique son raisonnement en tant que tel:

Pour tester le comportement de Listing 8.22, nous pouvons ajouter une ligne à l'épreuve de Listing 7.26 pour vérifier que l'utilisateur est connecté Il est utile dans ce contexte de définir un is_logged_in.? méthode d'assistance pour mettre en parallèle le logged_in? helper défini dans Listing 8.15, qui renvoie true si l'ID utilisateur est dans la session (test) et false dans le cas contraire (Listing 8.23). (Comme les méthodes auxiliaires ne sont pas disponibles dans les tests, nous ne pouvons pas utiliser current_user comme dans Listing 8.15, mais la méthode de session est disponible, donc nous l'utilisons à la place.) Ici, nous utilisons is_logged_in? au lieu de logged_in? de sorte que les méthodes helper de test et Sessions helper ont des noms différents, ce qui les empêche de se confondre.

Cependant, dans un exercice du chapitre 5, l'auteur écrit y compris le code ApplicationHelper dans sa suite de tests (voir Listing 5.37):

ENV['RAILS_ENV'] ||= 'test' 
. 
. 
. 
class ActiveSupport::TestCase 
    fixtures :all 
    include ApplicationHelper 
    . 
    . 
    . 
end 

Quand j'inclus SessionsHelper et couru mes tests en utilisant le code de cette aide module, mes tests sont toujours passés. Je me demandais si l'auteur a choisi de renoncer, y compris SessionsHelper dans le code parce que cette technique a été utilisée dans un exercice (et donc mieux appliquée ailleurs) ou si effectivement inclure SessionsHelper à la suite de tests est une mauvaise chose pour une raison ou une autre. Des idées à ce sujet?

Répondre

0

Après avoir traversé le chapitre 8, je trouve que le test pour savoir si l'utilisateur est connecté en utilisant le code de logged_in? (c.-à-!current_user.nil?) ne fonctionnera pas pour les tests en quelque sorte, la méthode current_user ne fonctionne pas réellement (c.-à- , en quelque sorte, il renvoie toujours true). Bien que je ne sais pas exactement pourquoi; Je baserai cette citation:

(Parce que les méthodes auxiliaires ne sont pas disponibles dans les tests, nous ne pouvons pas utiliser current_user comme dans le Listing 8.15, mais la méthode de session est disponible, donc nous utilisons cette méthode au lieu de cela.)

Donc, en utilisant essentiellement la méthode current_user dans les tests ne fonctionnera pas parce que ce n'est pas disponible dans les tests? (Je pensais que je les ai inclus dans test_helper.rb avec la ligne include SessionsHelper, bien que

Voici ma réponse pour l'instant Ce serait génial si quelqu'un de plus compétent que moi pourrait confirmer le fonctionnement interne de ce

EDIT...: Ok, donc je pense que c'est parce que la méthode current_user utilise @current_user ||= User.find_by(id: user_id) mais la base de données User est différente entre le développement et le test