Rspec, des Rails: comment faire pour tester les méthodes privées de contrôleurs?

J'ai contrôleur:

class AccountController < ApplicationController
  def index
  end

  private
  def current_account
    @current_account ||= current_user.account
  end
end

Comment tester la méthode privée current_account avec rspec?

P. S.-je utiliser Rspec2 et Ruby on Rails 3

Cela ne veut pas répondre à votre question, mais les méthodes privées ne sont pas censés être testé. Vos tests doivent seulement se soucient de la vraie chose - votre API publique. Si vos méthodes de travail, puis privé de ceux qu'ils appellent aussi le travail.
Je suis en désaccord. Il est important de tester n'importe quel suffisamment complexe pour la fonctionnalité dans votre code.
Je suis en désaccord aussi. Si votre public API travaille, vous ne pouvez assumer vos méthodes privées fonctionnent comme prévu. Mais vos spécifications peut-être en passant par une coïncidence.
Il serait préférable d'extraire la méthode privée dans une nouvelle classe qui est testable, si la méthode privée besoins de test.
Le cadre du point de l'unité de test est d'aider à briser votre logique bas en testables composants. Parfois, ces petits composants n'a de sens que les méthodes privées, des choses qui ne sont pas appelés de l'extérieur de la classe -- mais ils ont encore besoin d'être testé. Comme le nombre de méthodes privées augmente, le nombre de tests vous avez besoin de tester chacun de ces sous-méthodes augmente géométriquement, comme vous êtes maintenant faut tester chaque permutation des entrées possibles pour tester chaque cas d'utilisation.
Vous avez raison. Avec plus de recul et l'expérience, je suis en désaccord avec mes trois ans de commentaire. 🙂
Les joies de google, le rendant facile à oublier datetime des timbres depuis l'année 2000.
Voulant tester une méthode privée est un bon signe que la classe d'origine a trop de responsabilités. Il y a des exceptions à tout, bien sûr. Mais souvent nous inventer des exceptions, car le refactoring est dur.

InformationsquelleAutor petRUShka | 2010-11-24

rspec ruby-on-rails

190

Utiliser #instance_eval
```
@controller = AccountController.new
@controller.instance_eval{ current_account }   # invoke the private method
@controller.instance_eval{ @current_account }.should eql ... # check the value of the instance variable
```
- Si vous préférez, vous pouvez aussi dire: @contrôleur.envoyer(:current_account).
- Ruby vous permet d'appeler des méthodes privées avec envoyer, mais cela ne veut pas nécessairement dire que vous devez. Essais de méthodes privées se fait à travers les tests de l'interface publique de ces méthodes. Cette approche fonctionne, mais ce n'est pas idéal. Ce serait mieux si la méthode a été dans un module qui a été inclus dans le contrôleur. Ensuite, il pourrait être testé de façon indépendante de l'appareil en tant que bien.
- Même si, cette réponse techniquement répond à la question, je suis downvoting elle, parce qu'elle viole les meilleures pratiques dans les tests. Les méthodes privées ne doivent pas être testés, et juste parce que Ruby vous donne la possibilité de contourner la visibilité des méthodes, cela ne signifie pas que vous devriez en abuser.
- Srdjan Pejic pourriez-vous expliquer pourquoi les méthodes privées ne doivent pas être testés?
- Je suis d'accord que vous ne devriez pas tester les méthodes privées NORMALEMENT, mais vous ne devriez pas vous exposer quelque chose, mais les actions sur les rails de contrôleur, et parfois une méthode privée est appelée sur un before_filter ou quelque chose comme ça. À mon humble avis, si ce n'est pas un cas simple, il doit être testé.
- upvoting ce b/c il ne faut pas être conférences sur les bonnes/mauvaises pratiques, le gars a juste besoin de tester sa méthode privée. J'ai été là.
- Je pense que vous downvote des réponses qui sont mal ou de ne pas répondre à la question. Cette réponse est correcte et ne devrait pas être downvoted. Si vous êtes en désaccord avec la pratique de tests méthodes privées, mettez les dans les commentaires que c'est de la bonne info (comme beaucoup l'ont fait) et puis les gens peuvent upvote ce commentaire, qui montre votre point sans inutilement downvoting un prefectly réponse valable.
- Nouvelle syntaxe de rspec : attendre(@contrôleur.instance_eval{ current_account }).pour eql ...
InformationsquelleAutor monocle
37

Je utiliser la méthode send. Par exemple:
```
event.send(:private_method).should == 2
```
Car "envoyer" peut appeler les méthodes privées
- Comment voulez-vous tester les variables d'instance dans le secteur privé de la méthode à l'aide de .send?
InformationsquelleAutor graffzon
23

Où est le current_account méthode utilisée? Quel but a-t-elle?

En général, vous n'avez pas fait de test des méthodes privées, mais plutôt de tester les méthodes qui font appel au privé.
- Je veux avoir current_account méthode dans les contrôleurs et les vues que helper_method, mais je ne veux pas avoir d'action current_account.
- Idéalement, on devrait tester chaque méthode. J'ai utilisé les deux sujets.envoyer et le sujet.instance_eval avec beaucoup de succès dans rspec
- Je suis en désaccord, vous devriez tester le public les méthodes de l'API qui sera appel le privé, comme ma réponse originale à cette question dit. Vous devriez tester l'API que vous fournissez, pas le privé méthodes que vous pouvez voir.
- Je suis d'accord avec @Ryan Bigg. Vous ne pas tester des méthodes privées. Cela supprime votre capacité de revoir ou de modifier la mise en œuvre de ladite méthode, même si ce changement n'affecte pas le public, les parties de votre code. Veuillez lire sur les meilleures pratiques lors de l'écriture de tests automatisés.
- Hmm, peut-être que je manque quelque chose. Les classes j'écris eu beaucoup plus de méthodes privées que celles du public. Seuls les tests par le biais de l'API publique entraînerait une liste de plusieurs centaines de tests qui ne font pas un miroir le code qu'ils sont à l'essai.
- J'ai un couple de méthodes utilisées dans before_filters sur mon contrôleur d'application qui sont définis comme des méthodes privées de ce contrôleur. Dans certains cas, je peux juste tester que le résultat de la méthode s'est produite, mais dans d'autres, je veux tester que la fonction est de retour ce qu'il est censé. Prenez par exemple une fonction qui charge une ressource partagée modèle pour toutes les demandes de page. Je veux assurez-vous que la variable d'instance est correctement définie, ce qui je ne peux le faire en testant la méthode privée elle-même.
- Selon ma compréhension, si vous voulez obtenir réel de granularité dans les tests unitaires des méthodes privées doivent également être testés. Si vous voulez de refactoriser le code de test de l'unité doit également être remaniée en conséquence. Cela garantit votre nouveau code fonctionne également comme prévu.
InformationsquelleAutor Ryan Bigg
8

Vous devriez pas tester vos méthodes privées directement, ils peuvent et doivent être testés indirectement par l'exercice du code de méthodes publiques.

Cela vous permet de modifier les données internes de votre code en bas de la route sans avoir à changer vos tests.

InformationsquelleAutor Xinyang Li
4

Vous pourriez faire de vous des méthodes privées ou protégées en tant que public:
```
MyClass.send(:public, *MyClass.protected_instance_methods) 
MyClass.send(:public, *MyClass.private_instance_methods)
```
Il suffit de placer ce code dans votre essai de la classe en remplaçant votre nom de classe. Inclure l'espace de noms, le cas échéant.

InformationsquelleAutor zishe

require 'spec_helper'

describe AdminsController do 
  it "-current_account should return correct value" do
    class AccountController
      def test_current_account
        current_account           
      end
    end

    account_constroller = AccountController.new
    account_controller.test_current_account.should be_correct             

   end
end

InformationsquelleAutor speedingdeer

1

Tests unitaires méthodes privées semble trop hors contexte avec le comportement de l'application.

Vous écrivez votre code d'appel en premier?
Ce code n'est pas appelée dans votre exemple.

Le comportement est la suivante: vous voulez un objet chargé à partir d'un autre objet.
```
context "When I am logged in"
  let(:user) { create(:user) }
  before { login_as user }

  context "with an account"
    let(:account) { create(:account) }
    before { user.update_attribute :account_id, account.id }

    context "viewing the list of accounts" do
      before { get :index }

      it "should load the current users account" do
        assigns(:current_account).should == account
      end
    end
  end
end
```
Pourquoi tu veux écrire le test hors contexte du comportement que vous
devrait être d'essayer de décrire?

Fait ce code obtenir utilisé dans beaucoup d'endroits?
Besoin d'une approche plus générique?

https://www.relishapp.com/rspec/rspec-rails/v/2-8/docs/controller-specs/anonymous-controller

InformationsquelleAutor Brent Greeff

Utiliser le rspec-contexte-privé gem pour rendre temporairement privé méthodes publiques dans un contexte.

gem 'rspec-context-private'

Il fonctionne par l'ajout d'un contexte partagé à votre projet.

RSpec.shared_context 'private', private: true do

  before :all do
    described_class.class_eval do
      @original_private_instance_methods = private_instance_methods
      public *@original_private_instance_methods
    end
  end

  after :all do
    described_class.class_eval do
      private *@original_private_instance_methods
    end
  end

end

Alors, si vous passez :private que les métadonnées d'un describe bloc, les méthodes privées sera public dans ce contexte.

describe AccountController, :private do
  it 'can test private methods' do
    expect{subject.current_account}.not_to raise_error
  end
end

InformationsquelleAutor barelyknown

0

Si vous avez besoin de tester une fonction privée créer une méthode publique qui appelle le secteur privé.
- Je suppose que vous voulez dire que cela devrait être fait dans votre code de test unitaire. C'est essentiellement ce .instance_eval et .envoyer le faire en une seule ligne de code. (Et qui veut écrire plus des tests quand un plus court a le même effet?)
- soupir, c'est un rails de contrôleur. La méthode doit être privé. Merci pour la lecture de la question.
- Vous pouvez toujours abstrait de la méthode privée pour une méthode publique dans un objet de service et de référence de cette façon. De cette façon, vous pouvez avoir tester uniquement les méthodes publiques, et pourtant toujours garder votre code SEC.
InformationsquelleAutor liamfriel

Je sais que c'est un peu hacky, mais cela fonctionne si vous voulez les méthodes testable par rspec, mais n'est pas visible dans prod.

class Foo
  def public_method
    #some stuff
  end

  eval('private') unless Rails.env == 'test'

  def testable_private_method
    # You can test me if you set RAILS_ENV=test
  end 
end

Maintenant, quand vous pouvez exécuter vous êtes spec comme suit:

RAILS_ENV=test bundle exec rspec spec/foo_spec.rb

InformationsquelleAutor onetwopunch

Vous devez vous connecter pour publier un commentaire.