Il est difficile de vérifier manuellement tous les différents comportements d'une application. Par conséquent, en écrivant un test, il est possible de vérifier efficacement si les données sont correctement transmises et si elles se comportent comme prévu.
Le framework de test Ruby le plus connu
Il existe plusieurs types de tests utilisés dans le didacticiel Rails.
Il existe un test unitaire qui vérifie le fonctionnement d'un seul modèle ou assistant de vue, un test de fonction qui vérifie le résultat de l'appel d'un contrôleur / d'une vue et un test intégré qui vérifie le comportement d'une application qui s'étend sur plusieurs contrôleurs, en supposant les opérations réelles de l'utilisateur. En développement, les tests ci-dessus sont souvent effectués.
Mettez la gemme pour rspec dans le Gemfile
group :development, :test do
gem 'rspec-rails'
end
après,
$ bundle install
Laisser.
Si nécessaire, incluez FactoryBot (anciennement FactoryGirl). Références: https://qiita.com/at-946/items/aaff42e4a9c2e4dd58ed
describe , it , expect Vous pouvez les utiliser pour décrire vos exigences de test.
Par exemple, dans un test unitaire (test de modèle)
spec/company_spec.rb
RSpec.describe Account, type: :model do
describe 'company model' do
it 'Créer' do
expect { create(:company) }.to change { Company.count }.by(1)
end
end
end
Lorsqu'une erreur se produit dans Rspec, le texte décrit dans le contexte et il est généré. Cela vous donnera une idée de l'endroit où l'erreur s'est produite.
context Vous pouvez également utiliser le contexte pour créer une branche de la condition. Vous pouvez créer chacun d'eux Par exemple, dans le test du contrôleur
spec/company_spec.rb
RSpec.describe CompaniesController, type: :controller do
describe 'Obtenir la liste' do
context 'Si vous êtes connecté' do
it 'Renvoie 200' do
//Processus de test
end
end
context 'Si vous n'êtes pas connecté' do
it 'Renvoie une erreur 400' do
//Processus de test
end
end
end
end
| Classification | Décrire |
|---|---|
| describe | Sujet au test |
| context | Décrire la classification des cas de conditions spécifiques |
| it | Décrivez ce qu'est le résultat |
Après avoir décrit le comportement comme ci-dessus, nous écrirons le test.
let , let!
Lorsque vous utilisez des données de test dans le test, décrivez ce traitement. Par exemple
spec/company_spec.rb
RSpec.describe CompaniesController, type: :controller do
describe 'Obtenir la liste' do
context 'Si vous êtes connecté' do
it 'Renvoie 200' do
let(:company) { Company.create(name: 'Yamada Co., Ltd.', email: '[email protected]') }
#Processus de test
end
end
context 'Si vous n'êtes pas connecté' do
it 'Renvoie une erreur 400' do
#Processus de test
end
end
end
end
Créez des données dans la partie où vous écrivez le processus comme décrit ci-dessus.
laissez laisser! est chacun
| Classification | Calendrier d'évaluation |
|---|---|
| let | Traité lors du premier appel de la méthode |
| let! | Traité avant l'exécution du bloc |
En d'autres termes, dans l'exemple ci-dessus
let(:company) { Company.new(name: 'Yamada Co., Ltd.', email: '[email protected]') }
À ce stade,: la société n'a pas été créée Par exemple
process :show, method: :get, params: { company_id: company.id }
La différence est qu'il est créé lorsque la société est appelée, comme dans.
Une erreur peut se produire en raison de la différence dans le moment de l'appel, donc cette différence est quelque chose dont je veux être conscient.
before / after Si vous souhaitez effectuer un processus avant et après le test, décrivez-le ici.
Les données créées par Rspec sont essentiellement supprimées de la base de données de test après le test.
Je vais résumer ce que je dérange personnellement avec Rspec. Je vous serais reconnaissant si vous pouviez signaler des erreurs!
https://qiita.com/jnchito/items/42193d066bd61c740612#context-%E3%81%A7%E6%9D%A1%E4%BB%B6%E5%88%A5%E3%81%AB%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97%E5%8C%96%E3%81%99%E3%82%8B https://qiita.com/uchiko/items/d34c5d1298934252f58f
Recommended Posts