[RUBY] Informationen zur Verzeichnisstruktur von RSpec und zur Rolle der einzelnen Spezifikationen
Einführung
In Bezug auf das Testframework der derzeit erstellten Webanwendung migrieren wir unter Berücksichtigung von Zuletzt erstellter Artikel von Minitest zu RSpec. Zu dieser Zeit hielt ich es für notwendig, die Arten von Tests zu kennen, die Minitest nicht sehr gut kannte. Wie ein Test geschrieben wird, hängt davon ab, ob es sich bei dem Test um einen UI-Test, einen Controller-Test oder einen Modelltest handelt. Dieser Artikel fasst kurz die RSpec-Verzeichnisstruktur und das Schreiben von Code für jeden Testtyp zusammen. Ich habe darauf verwiesen → Einführung in RSpec, das verwendet werden kann, Teil 1 "Grundlegende Syntax und nützliche Funktionen von RSpec verstehen" Everyday Rails-Einführung in das Testen von Rails mit RSpec
Hauptverzeichnisse von RSpec
Die Art des RSpec-Tests heißt Spec. Spezifikationen werden normalerweise in einer legitimen Verzeichnisstruktur abgelegt, die ihren Zweck beschreibt.
** [Haupt-RSpec-Verzeichnisstruktur] **
spec --- Modelle ｜ ｜ ー Anfragen ｜ ｜ ー Funktionen ｜ ｜ ー Helfer ｜ ｜ ー Mailer ｜ ｜ ー System
Über die Hauptrolle von Spec
Hier werden die Rollen von ** Modellspezifikation **, ** Anforderungsspezifikation **, ** Funktionsspezifikation ** und ** Systemspezifikation ** vorgestellt.
Model Spec Modellspezifikationstests Schienenmodelle wie die Validierung. Überprüfen Sie mit dem folgenden Beispielcode.
spec/models/user_spec.rb
RSpec.describe User, type: :model do
describe 'Nutzername' do
it 'Wenn leer, ist es in einem ungültigen Zustand' do
user = User.new( name: ' ',
email: '[email protected]',
password: 'password',
password_confirmation: 'password')
expect(user).to_not be_valid
end
it 'Wenn es zu lang ist, ist es in einem ungültigen Zustand' do
user = User.new( name: 'a' * 51,
email: '[email protected]',
password: 'password',
password_confirmation: 'password')
expect(user).to_not be_valid
end
end
end
Ich werde den Inhalt einzeln überprüfen.
- Geben Sie die Spezifikation mit
type :: modelan. Wir testen hier das Benutzermodell.
· Beschreiben gruppiert die erwarteten Ergebnisse.
Es deklariert darin "das Benutzermodell testen" und "den Benutzernamen testen".
- User.new erstellt einen Benutzer.
- Es ist in Einheiten gruppiert, die kleiner sind als beschreiben, genannt ** Beispiel **.
Sie können mehrere Erwartungen innerhalb von "es" haben. Wenn es jedoch in der Mitte fehlschlägt, fließt es danach nicht mehr. Daher wird grundsätzlich eine Erwartung für jedes "es" empfohlen.
・ Expect beschreibt die Erwartung (Erwartung).
require (user) .to_not be_valid testet "Ist der Benutzer gültig?"
Einer der Vorteile von RSpec ist, dass Sie Tests wie auf Englisch schreiben können.
Der Teil to_not be_valid heißt ** matcher ** und es gibt verschiedene Typen.
Weitere Matcher finden Sie unter hier.
Request Spec Die Anforderungsspezifikation entspricht der offiziellen Dokumentation (https://relishapp.com/rspec/rspec-rails/v/4-0/docs/request-specs/request-spec). , Es ist so ausgelegt, dass der Betrieb ohne Stummel [^ 1] betrieben wird. " Der Punkt ist, dass es sich um einen serverseitigen Test handelt. Mit der Anforderungsspezifikation können Sie beim Testen der Controller-Antwort HTTP-Methoden (Abrufen, Veröffentlichen, Löschen usw.) verwenden.
spec/requests/access_to_users_spec.rb
RSpec.describe "AccessToUsers", type: :request do
describe 'Zugriffsbeschränkungen für Benutzer, die nicht angemeldet sind' do
it 'Benutzer löschen' do
user = User.create( name: 'kojiro',
email: '[email protected]',
password: 'password',
password_confirmation: 'password')
expect {
delete user_path(user)
}.to change(User, :count).by(0)
end
end
end
Hier verwenden wir die Methode "Löschen", um zu testen, ob ein Benutzer, der nicht angemeldet ist, das Löschen des Benutzers nicht widerspiegelt.
erwarten, dass {Benutzerpfad löschen (Benutzer)} .zu ändern (Benutzer,: Anzahl) .by (0) bedeutet, dass beim Zugriff auf Benutzerpfad löschen (Benutzer) der Unterschied in der Anzahl der Benutzer vor und nach dem Zugriff 0 beträgt. Voraussagen. "
Feature Spec Feature Spec ist ein UI-Test. Offizielles Dokument empfiehlt die Verwendung von System Spec, das ähnliche Funktionen wie RSpec 3.7 bietet. tun.
System Spec System Spec ist wie Feature Spec in erster Linie ein UI-Test. Sie können einen E2E-Test (End-to-End) schreiben, der in Ihrem Browser ausgeführt wird. Dies ist ein Fronttest. Außerdem führen wir standardmäßig Tests mit dem Chrome-Browser durch. Verwenden Sie ** Capybara **, um die Browseraktivität zu simulieren. Wir werden anhand des folgenden Beispielcodes überprüfen, um welche Art von Beschreibung es sich handelt.
spec/systems/user_logins_spec.rb
RSpec.describe "UsersLogins", type: :system do
it 'Gültiger Login' do
user = User.create( name: 'kojiro',
email: '[email protected]',
password: 'password',
password_confirmation: 'password')
visit login_path
fill_in 'Mail Adresse', with: '[email protected]'
fill_in 'Passwort', with: 'password'
click_button 'Einloggen'
expect(current_path).to eq user_path(user)
end
end
Ich werde den Inhalt einzeln überprüfen.
- Erstellen Sie zunächst einen Benutzer mit "User.create" und speichern Sie ihn.
-Methoden wie visit, fill_in und click_button sind Capybaras domänenspezifische Sprachen namens DSL.
visitsteht für einen Besuch der Seite. Verwenden Sievisit login_path, um zur Anmeldeseite zu gelangen.fill_inrepräsentiert die Eingabe von Zeichen in das Textfeld. Infill_in'email address 'mit:' user @ example.com'haben Sie '[email protected]' in das Textfeld 'email address' eingegeben.click_buttonStellt einen Schaltflächenklick dar.
Weitere DSLs finden Sie unter hier.
-Expect (current_path) .to eq user_path (user) testet "ob der aktuelle Pfad mit user_path (user) (user details) identisch ist".
Wenn der Test fehlschlägt, zeigt die Systemspezifikation außerdem einen Screenshot des fehlgeschlagenen Teils zusammen mit einer Fehlermeldung des fehlgeschlagenen Inhalts an. Ändern Sie als Test den "Benutzerpfad (Benutzer)" der Vorhersage in "Anmeldepfad" und führen Sie den Test aus. Dann wurde die folgende Ausgabe ausgegeben.
Failures:
1)UsersLogins Gültige Anmeldung, Abmeldung
Failure/Error: expect(current_path).to eq login_path
expected: "/login"
got: "/users/1"
(compared using ==)
[Screenshot]: /(Programmpfad)/myapp/tmp/screenshots/failures_r_spec_example_groups_users_logins_Gültiges Login, abmelden_119.png
# ./spec/system/users_login_spec.rb:14:in `block (2 levels) in <top (required)>'
Wie Sie im Screenshot sehen können, sehen Sie "Benutzerpfad (Benutzer)" (Benutzerdetailbildschirm) anstelle von "Anmeldepfad" (Anmeldebildschirm), mit dem Sie das Ergebnis erwartet haben.
Zusammenfassung
Übrigens kann in Request Spec Capybara nicht verwendet werden, und in Feature Spec kann die HTTP-Methode nicht verwendet werden. Es muss festgestellt werden, ob der Test, den Sie implementieren möchten, die Serverseite oder die Vorderseite ist.
[^ 1]: Ein Stub ist ein Ersatz für ein Untermodul, das ein Modul beim Testen eines Moduls in einem Computerprogramm aufruft. ([wiki](https://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%BF%E3%83%96#:~:text=%E3%82%B9%E3% 82% BF% E3% 83% 96% EF% BC% 88stub% EF% BC% 89% E3% 81% A8% E3% 81% AF% E3% 80% 81,% E7% 94% A8% E3% 81 % 84% E3% 82% 8B% E4% BB% A3% E7% 94% A8% E5% 93% 81% E3% 81% AE% E3% 81% 93% E3% 81% A8% E3% 80% 82 & Text =% E9% 80% 86% E3% 81% AB% E4% B8% 8A% E4% BD% 8D% E3% 83% A2% E3% 82% B8% E3% 83% A5% E3% 83% BC% E3% 83% AB% E3% 81% AE,% E3% 82% A6% E3% 82% A7% E3% 82% A2% E3% 81% AE% E5% A0% B4% E5% 90% 88% EF Von% BC% 89% E3% 81% A8% E5% 91% BC% E3% 81% B6% E3% 80% 82)) Hier arbeitet Rails im Test ohne Ersatz für das untere Modul. Kann fahren.