[RUBY] Rspec, TDD (1)

Freut mich, dich kennenzulernen. Ab April wechselte ich meinen Job von der medizinischen Industrie zu einem Webingenieur. Ruby Erfahrung ist ungefähr 2 Monate.

Es ist anderthalb Monate her, seit ich in das Unternehmen eingetreten bin, und zusätzlich zu geringfügigen Korrekturen habe ich nach und nach neue Funktionen entwickelt, und ich spüre das Wachstum nach und nach (das sage ich Ihnen).

Bei der Entwicklung einer neuen Funktion wurde mir gesagt, "Bitte schreibe einen Test", und als ich mir den Testcode ansah, befand ich mich in dem Zustand "Ich weiß nicht, wie ich schreiben soll ...", daher gab ich dem Studium des Tests Priorität. Ich bin. Ich weiß irgendwie (ich fühle), unter welchen Bedingungen der Test durchgeführt werden sollte, aber ich denke, es ist notwendig, sich an die Notation zu gewöhnen, die Rspec eigen ist.

Derzeit studiere ich mit Bezug auf die folgenden Bücher und Artikel. Everyday Rails-Einführung in das Testen von Rails mit RSpec Einführung in RSpec, das verwendet werden kann, Teil 1 "Grundlegendes zur Syntax und nützlichen Funktionen von RSpec" Testgetriebene Entwicklung

Zur Erinnerung, ich werde den Prozess des Studierens des Tests nach und nach als Artikel verlassen.

Erstens, wenn Sie dem Test, den Sie geschrieben haben, nicht vertrauen können, startet er nicht ...

Was sind die Vorteile eines Tests überhaupt?

1. Kostensenkung für den gesamten Test

―― Indem Sie automatisch automatische Tests schreiben, können Sie neue Funktionen entwickeln und gleichzeitig bestätigen, dass vorhandene Funktionen wie erwartet funktionieren. ――Es kann garantiert werden, dass die ursprüngliche Funktion beim Refactoring nicht zerstört wird.

2. Werden Sie resistent gegen Veränderungen in der Umwelt

• Sie können die Auswirkungen von Versionsänderungen wie Rubin-, Schienen- und Edelsteinaktualisierungen untersuchen.

3. Der Test selbst wird zum Verwendungsdokument

――Es hilft anderen, die Spezifikationen zu verstehen, da es die Details des erwarteten Verhaltens anzeigt.

• Es wird eine Gelegenheit sein, die Spezifikationen und die Schnittstelle zu überdenken

4. Hilft bei der Aufrechterhaltung der Code-Granularität

• Methoden und Aktionen, die schwer zu schreiben sind, haben so viele Rollen, dass Sie die Möglichkeit haben, Ihre Implementierung zu überdenken.

5. Verbesserung der allgemeinen Entwicklungseffizienz

--Das ist alles. Die Entwicklung ist viel sicherer und sicherer als manuelle Tests und Gebetsbereitstellung

Rspec-Setup

• Gemfile hinzugefügt, da es standardmäßig nicht in Rails enthalten ist → Bundle-Installation

Gemfile

group :development, :test do
  gem 'rspec-rails', '~> 3.8.0'
end

--Erstellen einer Test-DB

config/database.yml

test:
  <<: *default
  database: db/test.sqlite3

Führen Sie bin / Rails aus. Db: create: all

Rspec-Einstellungen

Führen Sie bin / Rails g rspec: install aus Spezifikationsspeicherverzeichnis, Hilfsdatei, Einstellungsdatei werden erstellt

.rspec

--format documentation

Wenn Sie es hinzufügen, sind die Ausgabeinformationen leichter zu lesen.

• Installieren Sie Binstub und Feder, um die Effizienz des Rspec-Tests zu verbessern

Über binstub Über den Frühling

gemfile

group :development do
  gem 'spring-commands-rspec'
end

Führen Sie $ bundle exec spring binstub rspec aus Jetzt können Sie den Test mit $ bin / rspec ausführen

Überprüfen Sie zuerst die grundlegende Syntax

--describe: Testgruppierungsdeklaration, verschachtelbar --it: Gruppentests in Einheiten, die als Beispiele bezeichnet werden

• Erwarten Sie (A) .zu Gleichung B: Test, der erwartet, dass A B ist

sample_spec.rb

Rspec.describe 'Berechnung' do
  it '100 +100 ist 200' do
   expect(100 + 100).to eq 200
  end
  it '100 *100 ist 10000' do
    expect(100 * 100).to eq 10000
  end
end

--context: Nach Bedingung gruppieren --vorher: In vielen Fällen werden die Datenvorbereitung und Assets vor der Testausführung, die immer vor der Ausführung des Beispiels aufgerufen werden, ausgeführt.

• Seien Sie vorsichtig, wenn Sie Variablen verwenden, da diese zuvor unterschiedliche Bereiche haben.

--let (: A) {B}: B kann als A bezeichnet werden --let ist eine verzögerte Auswertung und wird erst verwendet, wenn es aufgerufen wird --let !: Der vor dem Ausführen des Beispiels definierte Wert wird erstellt. Dies ist möglicherweise besser, wenn der Test aufgrund einer verzögerten Auswertung fehlschlägt

--subject: Kann zu testende Objekte gruppieren

• In diesem Fall verwenden Sie is_expected

--shared_example, it_behaves_like: Kann wiederverwendet werden, wenn das Beispiel nicht DRY ist

--shared_context, include_context: Kontext kann wiederverwendet werden

Dies ist vorerst das Ende. Ich verstehe die Grundlagen, also werde ich immer mehr schreiben