RSpec 'Expect' Syntax und Idiomatic Attributesp

Question

Dies sollte eine einfache Antwort haben, aber ich habe Mühe, es zu finden (RSpec Dokumentation, EverydayRails Testing mit RSpec, Google-Ergebnisse überprüft). In meinem Modell Spezifikationen wie ich specs Grund Attribute umfassen wie folgt:

describe Foo do 
    describe "basic attributes" do 
    before { @foo = create(:foo) } 
    subject { @foo } 

    it { should be_valid } 
    it { should respond_to(:color) } 
    it { should respond_to(:height) } 
    it { should respond_to(:some_other_attribute) } 
    it { should respond_to(:you_get_the_idea) } 
    ... 

ich diese Spezifikationen mag, weil, wenn es irgendeine Art von Fehler in meiner Fabrik und/oder das Modell dieser Angaben helfen Sie mir, es schnell zu lokalisieren.

Ich habe die expect Syntax in alle anderen Spezifikationen eingebaut und ich mag, wie es liest, aber wie man es hier benutzt? Eine Option könnte

expect(@foo).to respond_to(:color) 

sein und ein anderer könnte

expect(it).to respond_to(:color) 

Erstere sein beinhaltet Vervielfältigung, die mit der should Syntax vermieden wird, aber letztere sieht seltsam mir (was nur ich sein könnte).

Ich weiß, dass diese Frage mehr über Stil als Funktionalität * ist, aber wir Ruby-Entwickler sind gewissenhaft in Bezug auf Stil, und ich möchte mich an Standardpraktiken halten und lesbaren, idiomatischen Code haben. Jede Hilfe wird geschätzt. Vielen Dank.

UPDATE: Keine meiner vorgeschlagenen Optionen funktioniert übrigens. Beide werfen undefined method 'expect' Fehler. Jetzt bin ich wirklich verwirrt!

Nachdem ich über den Fehler nachgedacht habe, merke ich, dass es ist, weil die should Spezifikationen oben innerhalb des einzeiligen Blockes sind. Die Verwirrung, wie kann ich dann einen einzeiligen Block mit der Expect-Syntax schreiben? Angesichts dieses Updates geht es in erster Linie um Funktionalität und ich bin gespannt darauf, die Gedanken anderer zu hören.

4/2015 UPDATE

rspec > 3.0 hat noch einen anderen Weg, um diese zu handhaben, hinzugefügt und es klingt wie rspec ~> 4.0 mit der should Syntax entfernt tun. Per Myron Masters:

Einige Benutzer haben sich darüber geärgert, wie sich dies auf die Expect-Syntax bezieht und ob Sie sie weiterhin verwenden können. Es wird auch weiterhin in RSpec 3 (wieder, unabhängig von Ihrer Syntax-Konfiguration) zur Verfügung stehen, aber wir haben auch hinzugefügt eine alternative API, die ein bisschen mehr im Einklang mit der erwarten ist Syntax:

describe Post do 
    it { is_expected.to allow_mass_assignment_of(:title) } 
end 

is_expected ist sehr einfach definiert als expect (subject) und unterstützt auch negative Erwartungen über is_expected.not_to matcher. [...]
In RSpec 3 haben wir die Soll-Syntax beibehalten und sind standardmäßig verfügbar. Sie erhalten jedoch eine Verwarnungswarnung, wenn Sie sie verwenden, ohne sie explizit zu aktivieren. Dies wird den Weg dafür bereiten, dass es standardmäßig in RSpec 4 deaktiviert wird (oder möglicherweise in ein separates Juwel extrahiert wird), während die Verwirrung für Neulinge, die über ein altes Tutorial zu RSpec kommen, minimiert wird.

Answer 1

Myron Marston, einem der RSpec Committer Kern, erklärt here, die Sie noch

it { should be_cool } 

Wenn Sie die should Syntax deaktiviert haben verwenden sollte, bietet er eine Lösung alias expect_it-it:

RSpec.configure do |c| 
    c.alias_example_to :expect_it 
end 

RSpec::Core::MemoizedHelpers.module_eval do 
    alias to should 
    alias to_not should_not 
end 

in diesem Ort, könnte man dies schreiben als:

describe User do 
    expect_it { to be_valid } 
end 

Answer 2

Ich glaube nicht, dass es eine richtige Antwort auf diese Frage, aber ich habe vor kurzem Umschreiben meine Test-Suiten wegzubewegen ausschließlich aus should und verwenden Sie die expect Syntax, also werde ich meine beiden werfen . Cent entschied ich mich ziemlich viel, weil Myron Marston, die RSpec führen Betreuers, wrote neu zu schreiben:

in Zukunft planen wir, die Standardeinstellungen zu ändern, so dass nur erwarten ist, wenn Sie explizit sollte ermöglichen. Wir können dies bereits mit RSpec 3.0 tun, aber wir möchten den Benutzern viel Zeit geben, um sich damit vertraut zu machen.

er auch commented:

Wir haben keine Pläne jemals entfernen „sollte“ ... aber erwarten weniger gotchas hat, und ist die Syntax I für neue Projekte empfehlen.

ich mit Mark Rushakoff ‚einverstanden Antwort s auch, aber persönlich möchte ich nicht, diese Aliase zu erstellen haben nur eine einzige it -Block Stil Syntax zu halten. Also, Ihr Beispiel mit, wo ich ursprünglich ein Modell spec wie Ihr Beispiel in dieser Form geschrieben:

describe Foo do 
    let(:foo) { create(:foo) } 
    subject { foo } 
    describe "model attributes" do 
    it { should be_valid } 
    it { should respond_to(:color) } 
    it { should respond_to(:height) } 
    it { should respond_to(:some_other_attribute) } 
    it { should respond_to(:you_get_the_idea) } 
    end 
    # ... 
end 

Ich würde jetzt neigen dazu, es zu schreiben:

describe Foo do 
    let(:foo) { create(:foo) } 
    specify "model attributes" do 
    expect(foo).to be_valid 
    expect(foo).to respond_to(:color) 
    expect(foo).to respond_to(:height) 
    expect(foo).to respond_to(:some_other_attribute) 
    expect(foo).to respond_to(:you_get_the_idea) 
    end 
    # ... 
end 

Meine Meinung ist foo dass Referenzierung direkt in expect(foo).to respond_to(:color) ist so viel "Duplizierung" als Verweis auf eine subject indirekt mit it, so bin ich nicht zu viel darüber, und ich bin auf die Art und Weise Erwärmung, die expect Spezifikationen in der Regel lesen. Aber letztendlich denke ich, dass dies nur eine Frage des bevorzugten Schreibstils ist.