Shoulda + FactoryGirl: Puis-je faire mes tests plus rapidement?

Question

Je suis à la recherche d'un moyen d'accélérer mes tests + FactoryGirl.

Le modèle que j'essaie de tester (StudentExam) a des associations avec d'autres modèles. Ces objets associés doivent exister avant que je puisse créer un StudentExam. Pour cette raison, ils sont créés en setup.

Cependant, un de nos modèles (School) prend beaucoup de temps à créer. Parce que setup est appelée avant chaque instruction should, le test complet prend des éons à exécuter - il crée un nouveau @school, @student, @topic et @exam pour chaque instruction should exécutée.

Je cherche un moyen de créer ces objets une fois et seulement une fois. Y a-t-il quelque chose comme une méthode startup pour before_all qui me permettrait de créer des enregistrements qui persisteront dans le reste du cas de test?

Fondamentalement, je suis à la recherche de quelque chose exactement comme before(:all) de RSpec. Je ne suis pas concerné par le problème des dépendances car ces tests ne modifieront jamais ces objets coûteux.

Voici un exemple de cas de test. Toutes mes excuses pour le long code (j'ai aussi créé un gist):

# A StudentExam represents an Exam taken by a Student. 
# It records the start/stop time, room number, etc. 
class StudentExamTest < ActiveSupport::TestCase 

    should_belong_to :student 
    should_belong_to :exam 

    setup do 
    # These objects need to be created before we can create a StudentExam. Tests will NOT modify these objects. 
    # @school is a very time-expensive model to create (associations, external API calls, etc). 
    # We need a way to create the @school *ONCE* -- there's no need to recreate it for every single test. 
    @school = Factory(:school) 
    @student = Factory(:student, :school => @school) 
    @topic = Factory(:topic, :school => @school) 
    @exam = Factory(:exam, :topic => @topic) 
    end 

    context "A StudentExam" do 

    setup do 
     @student_exam = Factory(:student_exam, :exam => @exam, :student => @student, :room_number => "WB 302") 
    end 

    should "take place at 'Some School'" do 
     assert_equal @student_exam, 'Some School' 
    end 

    should "be in_progress? when created" do 
     assert @student_exam.in_progress? 
    end 

    should "not be in_progress? when finish! is called" do 
     @student_exam.finish! 
     assert !@student_exam.in_progress 
    end 

    end 

end 

Answer 1

Si le problème ne crée ces enregistrements qu'une seule fois, vous pouvez utiliser une variable de classe. Ce n'est pas une approche propre mais au moins cela devrait fonctionner. EDIT: Pour corriger la super-solution de contournement, repoussez l'évaluation avec une méthode d'instance.

# A StudentExam represents an Exam taken by a Student. 
# It records the start/stop time, room number, etc. 
class StudentExamTest < ActiveSupport::TestCase 

    ... 

    private 

    def school 
     @@school ||= Factory(:school) 
    end 

    # use school instead of @@school 
    def student 
     @@school ||= Factory(:student, :school => school) 
    end 

end 

Answer 2

http://m.onkey.org/2009/9/20/make-your-shoulda-tests-faster-with-fast_context est un excellent article sur la façon de faire vos Shoulda/essais en usine fille plus rapide, en utilisant un petit bijou appelé fast_context. Faites-moi savoir si ce n'est pas ce dont vous avez besoin.

Answer 3

Il existe un plugin appelé fast_context (github link) qui combine les instructions should dans un contexte unique, accélérant les tests.

L'autre chose que j'utilise pour accélérer mes tests est de pré-remplir les données de l'appareil. FactoryGirl est lent car il crée ces enregistrements chaque fois que le bloc d'installation s'exécute.

J'ai écrit un plugin appelé Fixie qui utilise ActiveRecord pour pré-remplir la base de données de test, ainsi les enregistrements dont vous avez besoin pour vos tests sont déjà créés. Vous pouvez utiliser Fixie avec FactoryGirl si vous souhaitez également créer de nouveaux enregistrements lors de l'exécution.

Answer 4

Quel genre de tests essayez-vous d'écrire? Si vous voulez vraiment vous assurer que tous ces objets se coordonnent correctement, vous écrivez un test d'intégration et la vitesse n'est pas votre principale préoccupation. Cependant, si vous essayez de tester le modèle à l'unité, vous pouvez obtenir de meilleurs résultats en écrasant agressivement. Par exemple, si vous essayez de vérifier qu'un examen utilise le nom de son association scolaire lorsque vous appelez exam.location (ou ce que vous appelez), vous n'avez pas besoin d'un objet scolaire complet.Vous avez juste besoin de vous assurer que l'examen appelle la bonne méthode à l'école. Pour tester cela, vous pouvez faire quelque chose comme ce qui suit (en utilisant Test :: Unit et Mocha parce que ce que je suis au courant):

test "exam gets location from school name" do 
    school = stub_everything 
    school.expects(:name).returns(:a_school_name) 
    exam = Factory(:exam, :school => school) 

    assert_equal :a_school_name, exam.location 
end 

En gros, si vous avez besoin pour accélérer vos tests unitaires parce que les objets sont trop cher à construire, vous n'êtes pas vraiment un test unitaire. Tous les cas de test ci-dessus se sentent comme ils devraient être au niveau de test unitaire, donc talon tronqué!