🎯 Intention

Les scopes en Rails représente la passerelle entre le langage métier et une requête SQL.

L’objectif est que chacun(e) sache comment écrire un bon scope et le tester

<aside> ✅ Pré-requis

• Avoir des bases en SQL
• Avoir des bases en ActiveRecord </aside>

✅ Points clés

<aside> ⌛ Temps indicatif : 30min

</aside>

Etape

Visuel / Exemple

✍️ Créer un scope

• Le nom du scope doit utiliser le langage du Product Owner

• Un scope peut prendre un ou plusieurs arguments

• La requête SQL doit rester dans le cadre stricte du scope

  Pas includes, order ou autres superflus

Raison :

En utilisant le vocabulaire métier, il suffit de reprendre les mots du product owner en appelant les scopes pour réaliser sa demande.

Extraire une partie de la requête SQL permet aussi de simplifier l’écriture de test

scope :pour_le_jour, ->(*jours) { where('EXTRACT(ISODOW FROM date) IN (?)', jours.flatten) }
scope :uniquement_le_lundi,    -> { pour_le_jour(1) }

scope :sans_photo_detouree, -> { where.missing(:photo_detouree_attachment) }

# Ici on place la compléxité dans ce scope
# Le nom reprend les termes exactes données par le Product Owner
scope :pour_meteo_du_jour,
        lambda { |utilisateur|
          meteo = Meteo.du_jour.pour_utilisateur(utilisateur).first

          if meteo
            where('temperature_maximale >= ?', meteo.temperature_max)
              .where('temperature_minimale <= ?', meteo.temperature_min)
              .where('ARRAY[?] && conditions_meteo::text[]', meteo.temps)
          end
        }

🟢 Tester un scope

• Placer les tests dans le dossier spec/models/
• Les tests doivent au moins comporter :
  • un cas positif 👍
  • un cas négatif 👎
• Si le scope a des cas particuliers, ajouter un context par cas
• Les tests doivent être placés dans un describe : describe '.nom_du_scope' do

Raison :

Il s’agit de test d’intégration (et non unitaire !) car ces tests utilisent la base de donnée.

Le . avant le nom_du_scope dans le describe indique que l’on test une méthode de class

describe '.pour_meteo_du_jour' do
	# on évite de trop créer d'objet en amont pour la maintenabilité
	# on extrait la logique des context dans les [traits](<https://thoughtbot.com/blog/remove-duplication-with-factorybots-traits>)
  let(:utilisateur) { create(:utilisateur) }
	let!(:template_tenue) { create(:template_tenue, :ensoleille) }
  let(:resultat) { described_class.pour_meteo_du_jour(utilisateur) }

	# cas positif 👍
  context "quand l'utilisateur a une météo du jour" do
		before(:each) { create :meteo, :ensoleille, utilisateur: utilisateur }

    it 'retourne le template' do
      expect(resultat).to include template_tenue
    end
  end

	# cas négatif 👎
  context "quand l'utilisateur a une météo du jour mais avec une mauvaise temperature" do
		before(:each) { create :meteo, :glacial, utilisateur: utilisateur }

    it 'ne retourne pas le template' do
      expect(resultat).not_to include template_tenue
    end
  end

	# autre cas
  context "quand l'utilisateur n'a pas de météo" do
    it 'retourne tous les templates tenues' do
			expect(resultat.size).to eq TemplateTenue.all.count
    end
  end
end

❌ Erreurs type à éviter

• Tester uniquement le cas positif

• Le describe du scope dans le test doit être .ma_methode et non #ma_methode

  Better Specs. Testing Guidelines for Developers.

🎓Aller plus loin