La méthode que vous avez trouvée fonctionnera certainement pour tester un peu de fonctionnalité mais semble assez fragile - votre classe factice (en fait juste une Struct
dans votre solution) peut ou non se comporter comme une vraie classe qui include
est votre préoccupation. De plus, si vous essayez de tester les préoccupations du modèle, vous ne pourrez pas faire des choses comme tester la validité des objets ou invoquer des callbacks ActiveRecord à moins de configurer la base de données en conséquence (parce que votre classe factice n'aura pas de table de base de données pour la soutenir). De plus, vous voudrez non seulement tester la préoccupation, mais aussi tester le comportement de la préoccupation dans vos spécifications de modèle.
Alors pourquoi ne pas faire d'une pierre deux coups ? En utilisant l'outil RSpec groupes d'exemples partagés vous pouvez tester vos préoccupations par rapport aux classes qui les utilisent (par exemple, les modèles). et vous pourrez les tester partout où ils sont utilisés. Et vous n'avez qu'à écrire les tests une seule fois, puis à les inclure dans toute spécification de modèle qui utilise votre préoccupation. Dans votre cas, cela pourrait ressembler à quelque chose comme ceci :
# app/models/concerns/personable.rb
module Personable
extend ActiveSupport::Concern
def full_name
"#{first_name} #{last_name}"
end
end
# spec/concerns/personable_spec.rb
require 'spec_helper'
shared_examples_for "personable" do
let(:model) { described_class } # the class that includes the concern
it "has a full name" do
person = FactoryBot.build(model.to_s.underscore.to_sym, first_name: "Stewart", last_name: "Home")
expect(person.full_name).to eq("Stewart Home")
end
end
# spec/models/master_spec.rb
require 'spec_helper'
require Rails.root.join "spec/concerns/personable_spec.rb"
describe Master do
it_behaves_like "personable"
end
# spec/models/apprentice_spec.rb
require 'spec_helper'
describe Apprentice do
it_behaves_like "personable"
end
Les avantages de cette approche deviennent encore plus évidents lorsque vous commencez à faire des choses dans votre préoccupation comme invoquer des callbacks AR, où tout ce qui n'est pas un objet AR ne fera pas l'affaire.
0 votes
Quel cadre de test utilisez-vous ? N'oubliez pas non plus que Personable n'est qu'un module Ruby normal. Testez-le comme vous le feriez pour n'importe quel autre mixin.
0 votes
N'a pas
ActiveSupport::Concern
a été retiré de Rails ? Je pensais que ça avait disparu il y a un petit moment.0 votes
@LeeJarvis J'utilise Rspec et FactoryGirl.
0 votes
Ah, google m'informe que c'était seulement le
InstanceMethods
module intérieurConcern
qui a été supprimé. Je pense toujours que les préoccupations sont de mauvaise conception. Quel est le problème avec les objets de service ?2 votes
@KyleDecot stackoverflow.com/questions/1542945/testing-modules-in-rspec stackoverflow.com/questions/16453266/ benediktdeicke.com/2013/01/custom-rspec-example-groups Ceci devrait aider
0 votes
@Russell Rails 4 promeut activement les préoccupations (je suis également d'accord sur le fait que les objets de service sont une meilleure idée) mais malheureusement ce n'est pas comme ça que le noyau de Rails le voit. Les gens doivent juste se rappeler que ce sont juste des modules Ruby normaux et qu'ils doivent être utilisés de manière appropriée.
0 votes
@LeeJarvis Par "Rails core", je suppose que vous voulez dire "DHH". Ce n'est certainement pas une bonne idée de faire quelque chose juste parce que "Rails core" dit de le faire de cette façon.
4 votes
@Russell Je suis d'accord. Cela dit, je ne refuserais pas d'aider quelqu'un à répondre à ses questions simplement parce qu'il suit une façon de faire à la Rails et que je ne suis pas d'accord avec elle. De toute façon, je m'éloigne un peu du sujet de cette question :-)
0 votes
:-) Je suis d'accord. Désolé Kyle !
0 votes
Pas de problème. Il est toujours bon d'avoir l'avis d'autres développeurs sur le sujet que je traite actuellement.