[RUBY] RSpec-Ergebnisse der Überprüfung des Testcodes für die Benutzervalidierung

Einführung

Hallo zusammen! Qiitas Post, Rubin, Rails, Rspec-Anfänger J! Erst neulich machte ich mir Sorgen um "Was ist mit meiner Spezifikation aus professioneller Sicht?" Ich habe RSpec-Testing'users validation ' als Frage gepostet. Und das Video über Ruby und Rspec wird auf Youtube verbreitet. Ich ließ meinen Lehrer @jnchito eine Codeüberprüfung durchführen! Der Testcode war ziemlich lang, aber ich bat sie, jeden gründlich hervorzuheben. Er erklärte höflich "Ich würde das schreiben!" Danke dir,

Ich habe mich verlaufen und gefragt: "Was ist der Testcode, der den Regeln folgt?" Ich kann mich nicht leicht festlegen und wandere in der Hölle herum.

Ich fühle mich jetzt wie im Himmel! Vielen Dank für Ihre Bewertung. .. Weinen

Über @jnchito

Es ist berühmt, also wissen Sie es vielleicht, aber ...

• Einführung in Ruby für diejenigen, die professionell werden möchten Ich habe ein Buch über Rubin veröffentlicht,
• Everyday Rails-Einführung in das Testen von Rails mit RSpec Japanische Übersetzung von Büchern über rspec,
• Versuchen Sie, nur das Twitter-Konto im Text mit regulären Ausdrücken zu extrahieren Es gab auch Videos, die auf Youtube verbreitet wurden und Lernsitzungen abhielten!
• (1/2) Ich habe den auf Qiita veröffentlichten RSpec-Testcode überprüft Klicken Sie hier für das diesmal rezensierte Video!

Ein wirklich cooler Dandy-Lehrer! !!

Dieser Artikel ist also auch eine Ausgabe für mich, um ein Specker zu werden. Eine Referenz für Leute zu sein, die immer noch die gleichen Fähigkeiten wie ich haben Nach dem, was darauf hingewiesen und erklärt wurde, schaute ich auf meinen eigenen Code zurück und versuchte, die schlechten Punkte zu beheben! Bitte beziehen Sie sich darauf, wenn Sie möchten!

Mein Müllcode vor der Korrektur

Wenn Sie die Vorher- und Nachher-Testcodes mit dem vorherigen Code verbinden, ist die Qiita-Datenbank möglicherweise punktiert. ← (・ ・.) Wenn Sie also [Mein Müllcode vor der Änderung] vergleichen möchten (https://qiita.com/denjneb/items/36f0f86271b5ebd1a4d1#comment-9fb76aed6af4ca75cea5), duplizieren Sie bitte die Registerkarte!

Verschachteltes Bild von Spec

"Muss das Nest nicht zu tief sein?", Also habe ich es so flach wie möglich korrigiert!

RSpec.describe User, type: :model do
  describe 'attribute: name'
    context 'when present'
      it 'is valid'
        # ...Kürzung
      end
    end
  end
end

Der obige Inhalt lautet "Benutzer> Name> wenn vorhanden> gültig" In der englischen Übersetzung klingt es seltsam, aber jedes Nest ist ... Neu verschachtelt, um das Verständnis mit der Nuance "gültig, wenn der Benutzername vorhanden ist" zu erleichtern. Dies ist nur ein Bild!

Überarbeitet

Benutzermodell

app/models/user.rb

class User < ApplicationRecord
  before_save :downcase_email

  validates :name,
            presence: true,
            length: { maximum: 50 }
  VALID_EMAIL_REGEX = /\A[\w+\-.]+@[a-z\d\-]+(\.[a-z\d\-]+)*\.[a-z]+\z/i
  validates :email,
            presence: true,
            length: { maximum: 255 },
            format: { with: VALID_EMAIL_REGEX },
            uniqueness: { case_sensitive: false }

  private

    def downcase_email
      self.email = self.email.downcase
    end
end

Ergänzung

• VALID_EMAIL_REGEX = /\A[\w+\-.]+@[a-z\d\-]+(\.[a-z\d\-]+)*\.[a-z]+\z/i
  Von railstutorial "Nicht zwei aufeinanderfolgende Punkte abgleichen" Korrigiert zu diesem regulären Ausdruck. --self.email.downcase! Und destruktive Methoden werden selten verwendet. Es ist sicherer, keine destruktiven Methoden zu verwenden, da nicht bekannt ist, wann und wo in Zukunft auf sie verwiesen wird. ,,,Bestimmt. (Also wurde es unten behoben.)

def downcase_email
  self.email = self.email.downcase
end

FactoryBot

spec/factories/users.rb

FactoryBot.define do
  factory :user do
    name { 'Tony Stark' }
    email { '[email protected]' }
  end
end

Ergänzung

• Vor der Änderung: name {'hoge'}, email {" [email protected] "} Der Domain-Teil der E-Mail-Adresse, den ich für unmöglich hielt. .. Oh das? bar.com Klicken! Ich schwöre, ,,, @ example.com zu verwenden.

Spec

spec/models/user_spec.rb

require 'rails_helper'

RSpec.describe User, type: :model do
  let(:user) { FactoryBot.build(:user) }

  describe 'attribute: name' do
    context 'when present' do
      #Wenn der Name existiert, muss er gültig sein
      it 'is valid' do
        user.name = 'Tony Stark'
        expect(user).to be_valid
      end
    end

    context 'when blank' do
      #Wenn der Name leer ist, ist er ungültig
      it 'is invalid' do
        user.name = ' '
        expect(user).to be_invalid
        expect(user.errors[:name]).to include("can't be blank")
      end
    end

    context 'when empty' do
      #Ungültig, wenn der Name leer ist
      it 'is invalid' do
        user.name = ''
        expect(user).to be_invalid
        expect(user.errors[:name]).to include("can't be blank")
      end
    end

    context 'when nil' do
      #Ungültig, wenn der Name nicht existiert
      it 'is invalid' do
        user.name = nil
        expect(user).to be_invalid
        expect(user.errors[:name]).to include("can't be blank")
      end
    end

    context 'when length is 50 characters or less' do
      #Muss gültig sein, wenn der Name 50 Zeichen oder weniger enthält
      it 'is valid' do
        user.name = 'a' * 50
        expect(user).to be_valid
      end
    end

    context 'when length is more than 50 characters' do
      #Ungültig, wenn der Name mehr als 50 Zeichen enthält
      it 'is invalid' do
        user.name = 'a' * 51
        expect(user).to be_invalid
        expect(user.errors[:name]).to include('is too long (maximum is 50 characters)')
      end
    end
  end

  describe 'attribute: email' do
    context 'when present' do
      #Wenn eine E-Mail vorhanden ist, muss sie gültig sein
      it 'is invalid' do
        user.email = '[email protected]'
        expect(user).to be_valid
      end
    end

    context 'when blank' do
      #Wenn die E-Mail leer ist, ist sie ungültig
      it 'is invalid' do
        user.email = ' '
        expect(user).to be_invalid
        expect(user.errors[:email]).to include("can't be blank")
      end
    end

    context 'when empty' do
      #Ungültig, wenn die E-Mail leer ist
      it 'is invalid' do
        user.email = ''
        expect(user).to be_invalid
        expect(user.errors[:email]).to include("can't be blank")
      end
    end

    context 'when nil' do
      #Ungültig, wenn keine E-Mail vorhanden ist
      it 'is invalid' do
        user.email = nil
        expect(user).to be_invalid
        expect(user.errors[:email]).to include("can't be blank")
      end
    end

    context 'when length is 50 characters or less' do
      #Gültig, wenn die E-Mail-Adresse maximal 255 Zeichen beträgt
      it 'is valid' do
        user.email = 'a' * 243 + '@example.com'
        expect(user).to be_valid
      end
    end

    context 'when length is more than 50 characters' do
      #Ungültig, wenn E-Mail mehr als 255 Zeichen enthält
      it 'is invalid' do
        user.email = 'a' * 244 + '@example.com'
        expect(user).to be_invalid
        expect(user.errors[:email]).to include('is too long (maximum is 255 characters)')
      end
    end

    context 'when correct format' do
      #Wenn das E-Mail-Format korrekt ist, ist es gültig
      it 'is valid' do
        user.email = '[email protected]'
        expect(user).to be_valid

        user.email = '[email protected]'
        expect(user).to be_valid

        user.email = '[email protected]'
        expect(user).to be_valid

        user.email = '[email protected]'
        expect(user).to be_valid

        user.email = '[email protected]'
        expect(user).to be_valid
      end
    end

    context 'when is incorrect format' do
      #Ungültig, wenn das E-Mail-Format falsch ist
      it 'is invalid' do
        user.email = 'user@example,com'
        expect(user).to be_invalid

        user.email = 'user_at_foo.org'
        expect(user).to be_invalid

        user.email = 'user.name@example.'
        expect(user).to be_invalid

        user.email = 'foo@bar_baz.com'
        expect(user).to be_invalid

        user.email = 'foo@bar+baz.com'
        expect(user).to be_invalid
      end
    end

    context 'when already taken' do
      #Wenn dieselbe E-Mail bereits registriert ist, muss sie ungültig sein
      it 'is invalid' do
        FactoryBot.create(:user, email: '[email protected]')
        user.email = '[email protected]'
        expect(user).to be_invalid
        expect(user.errors[:email]).to include('has already been taken')
      end
    end

    context 'when case insensitive and not unipue' do
      #E-Mails unterscheiden nicht zwischen Groß- und Kleinschreibung und sind ungültig, wenn sie nicht eindeutig sind
      it 'is invalid' do
        FactoryBot.create(:user, email: '[email protected]')
        user.email = '[email protected]'
        expect(user).to be_invalid
        expect(user.errors[:email]).to include('has already been taken')
      end
    end

    #Die E-Mail wird in Kleinbuchstaben gespeichert
    it 'is saved in lowercase' do
      user.email = '[email protected]'
      user.save!
      expect(user.reload.email).to eq '[email protected]'
    end
  end
end

Ergänzung

--Teacher: Löschen Sie unnötige Debug-Codes. Ich: Ah ja! Aber beim Testen ist pry nützlich! --Teacher: Es ist nicht gut, die Benutzer von FactoryBot besuchen zu müssen. Ich: Auch wenn Sie einen Benutzer mit FactoryBot definieren, geben Sie unbedingt einen Wert in den Namen ein, bevor Sie die Exspektion schreiben! --I: Der Text von "Kontext" und "es" wurde korrigiert! --context: 'when ~' Gruppe wenn ~ --it: Valid gültiges Muster validieren Validiere ungültiges Muster Das Bild ist die Nuance des Kontexts des Teils des verschachtelten Bildes. ――Lehrer: Ich frage mich, ob Sie das Speichern nicht überprüfen müssen. .. Es kommt selten vor, dass die Validierung durchgeführt und gespeichert wird und wenn ein Rails-Fehler vorliegt oder so. Ich: Ich verstehe! (Gelöscht oder weniger.) Auszug aus unverändertem Code: expected (user.save) .to be_falsey --Teacher: Fassen wir den Test hier zusammen. "Ungültig, wenn Name nicht existiert" -- name = '' '(nur Leerzeichen) --name = '' (leer)

• name = nil（nil）

    context 'when name is blank' do
      #Wenn der Name nicht existiert, ist er ungültig
      it 'is invalid' do
        user.name = ' '
        expect(user).to be_invalid
        expect(user.errors[:name]).to include("can't be blank")

        user.name = ''
        expect(user).to be_invalid
        expect(user.errors[:name]).to include("can't be blank")

        user.name = nil
        expect(user).to be_invalid
        expect(user.errors[:name]).to include("can't be blank")
      end
    end

Ich: Ich wollte das schreiben, ohne es zusammenzusetzen, also habe ich es in "leer", "leer" und "null" unterteilt!

--I: Ich dachte, dass Nachrichten nicht in der Fehlermeldung enthalten sein würden, wenn ich nicht nach "user.valid?" Schreiben Sie also einfach "erwarten", ohne "user.valid" zu fragen. ――Lehrer: Regulärer Ausdruckstest, das ist gut! Ich: Azasu! --Lehrer: Trocken wegwerfen und in einer Variablen aufbewahren und dies oder das nicht tun! Wenn Sie eine Logik erstellen, tritt ein Fehler in dieser Logik auf und ein unerwarteter Unfall tritt auf. .. .. --Teacher: Soll ich "Eindeutigkeit: {case_sensitive: false}" testen? Ich: (2/2) Ich habe den auf Qiita veröffentlichten RSpec-Testcode überprüft Wie du siehst ...

• Speichern Sie gültige Benutzer mit niedrigeren E-Mail-Adressen.
• Geben Sie die oben registrierte Großbuchstaben-E-Mail des Benutzers erneut in die E-Mail-Adresse des Benutzers ein. --user ist ungültig. --Auch die Fehlermeldung enthält "wurde bereits vergeben". Ist der Code unten.

context 'when case insensitive and not unipue' do
  #E-Mails unterscheiden nicht zwischen Groß- und Kleinschreibung und sind ungültig, wenn sie nicht eindeutig sind
  it 'is invalid' do
    FactoryBot.create(:user, email: '[email protected]')
    user.email = '[email protected]'
    expect(user).to be_invalid
    expect(user.errors[:email]).to include('has already been taken')
  end
end

Zusammenfassung

Ich habe viel mehr Punkte, aber ich habe das professionelle Niveau noch nicht erreicht Ich werde das Video, das Sie überprüft und erklärt haben, überprüfen und den Teil, den ich verstanden habe, klarer beschreiben! Wenn Sie anfangen, einen Test zu schreiben, scheint es viele Kameraden zu geben, die nicht wissen, wie viel sie wie ich "testen" sollen. Ich denke, jeder hat unterschiedliche Meinungen, aber es ist perfekt für Anfänger!

"Glauben Sie an die Schienenvalidierung und testen Sie Ihre eigene und die Logik anderer!" '

Korrekt! Ich dachte, es wäre eine Verschwendung, die Überprüfung von Schienen zu testen ... Wie der Lehrer sagte, gibt es auch einige Dinge, die Sie nicht sagen können, wenn Sie es sagen. Ich denke, die Fähigkeit, die Testpunkte einzugrenzen, ist wichtiger. Ich denke, dass der Test für diese Validierung fast 100% korrekten Testcode hat, also Es wird eine zukünftige Praxis sein, die Logik zu testen, die Sie und Ihre Teammitglieder erstellt haben!

Dann alle!

Zum Testen trocken entsorgen, es sei denn, Sie benötigen es!

Jeder kann den Code leicht lesen und glücklich sein Mehr als alles,, Es macht keinen Sinn, wenn TEST falsch ist, w

wir sehen uns!

Testausgabe

User
  attribute: name
    when present
      is valid
    when blank
      is invalid
    when empty
      is invalid
    when nil
      is invalid
    when length is 50 characters or less
      is valid
    when length is more than 50 characters
      is invalid
  attribute: email
    is saved in lowercase
    when present
      is invalid
    when blank
      is invalid
    when empty
      is invalid
    when nil
      is invalid
    when length is 50 characters or less
      is valid
    when length is more than 50 characters
      is invalid
    when correct format
      is valid
    when is incorrect format
      is invalid
    when already taken
      is invalid
    when case insensitive and not unipue
      is invalid