Cú pháp RSpec 'Mong đợi' và thuộc tính Idiomatic

Question

Điều này cần có câu trả lời dễ dàng nhưng tôi đang cố gắng tìm nó (đã kiểm tra tài liệu RSpec, Kiểm tra EverydayRails với RSpec, kết quả của Google). Trong kỹ thuật mô hình của tôi, tôi muốn bao gồm thông số kỹ thuật thuộc tính cơ bản như sau:

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) } 
    ... 

Tôi thích những thông số kỹ thuật, vì nếu có một số loại lỗi trong máy của tôi và/hoặc mô hình hóa các thông số kỹ thuật giúp tôi xác định nó một cách nhanh chóng.

Tôi đã kết hợp cú pháp expect vào tất cả các thông số kỹ thuật khác và tôi thích cách đọc, nhưng cách sử dụng nó ở đây? Một lựa chọn có thể là

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

Và khác có thể

expect(it).to respond_to(:color) 

Cựu liên quan đến sự trùng lặp đó là tránh được với cú pháp should, nhưng sau này trông xa lạ với tôi (mà chỉ có thể là tôi).

Tôi nhận ra câu hỏi này mang tính phong cách hơn chức năng *, nhưng các nhà phát triển Ruby rất tận tâm về phong cách và tôi muốn tuân theo các thực hành tiêu chuẩn và có thể đọc được, mã thành ngữ. Bất kỳ trợ giúp được đánh giá cao. Cảm ơn.

CẬP NHẬT: Không có tùy chọn nào được đề xuất của tôi thực sự hoạt động, nhân tiện. Cả hai đều ném các lỗi undefined method 'expect'. Bây giờ tôi thực sự bối rối!

Có suy nghĩ về lỗi, tôi nhận ra rằng vì thông số kỹ thuật should ở trên nằm trong khối một dòng. Sự nhầm lẫn, sau đó, là làm thế nào tôi có thể viết một khối dòng với cú pháp mong đợi? Trong bản cập nhật này, câu hỏi là rất nhiều về chức năng và tôi sẽ vui mừng khi nghe suy nghĩ của người khác.

4/2015 CẬP NHẬT

rspec > 3.0 đã bổ sung thêm một cách xử lý này, và có vẻ như rspec ~> 4.0 sẽ loại bỏ các cú pháp should. Per Myron Masters:

Một số người dùng đã bày tỏ sự nhầm lẫn về cách thức này nên liên quan đến cú pháp mong đợi và nếu bạn có thể tiếp tục sử dụng nó. Nó sẽ tiếp tục có mặt tại RSpec 3 (một lần nữa, bất kể cấu hình cú pháp của bạn), nhưng chúng tôi cũng đã thêm một API thay thế đó là một chút phù hợp hơn với mong đợi cú pháp:

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

is_expected được định nghĩa rất đơn giản như mong đợi (chủ đề) và cũng hỗ trợ các kỳ vọng tiêu cực thông qua đối sánh is_expected.not_to. [...]
Trong RSpec 3, chúng tôi đã giữ nguyên cú pháp và có sẵn theo mặc định, nhưng bạn sẽ nhận được cảnh báo không dùng nữa nếu bạn sử dụng nó mà không bật nó một cách rõ ràng. Điều này sẽ mở đường cho nó bị vô hiệu hóa theo mặc định (hoặc có khả năng được tách thành một viên ngọc riêng biệt) trong RSpec 4, trong khi giảm thiểu sự nhầm lẫn cho người mới đến RSpec thông qua một hướng dẫn cũ.

Answer 1

Myron Marston, một trong những cốt lõi RSpec committers, giải thích here rằng bạn vẫn nên sử dụng

it { should be_cool } 

Nếu bạn đã vô hiệu hóa cú pháp should, ông đưa ra một giải pháp cho bí danh 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 

Với điều này tại chỗ, bạn có thể viết như sau:

describe User do 
    expect_it { to be_valid } 
end 

Answer 2

Tôi không nghĩ rằng có một câu trả lời đúng cho câu hỏi này, nhưng tôi đã gần đây đã được viết lại dãy phòng thử nghiệm của tôi di chuyển ra khỏi should và sử dụng cú pháp expect độc quyền, vì vậy tôi sẽ ném hai của tôi . cent trong tôi quyết định viết lại khá nhiều vì Myron Marston, các RSpec dẫn duy trì, wrote:

trong tương lai, chúng tôi dự định thay đổi giá trị mặc định để chỉ mong có sẵn, trừ khi bạn cho phép rõ ràng nên. Chúng tôi có thể làm điều này ngay sau khi RSpec 3.0, nhưng chúng tôi muốn cung cấp cho người dùng nhiều thời gian để làm quen với nó.

Ông cũng commented:

Chúng tôi không có kế hoạch bao giờ loại bỏ "nên" ... nhưng hy vọng có gotchas ít hơn, và là cú pháp Tôi muốn giới thiệu cho các dự án mới.

Tôi đồng ý với câu trả lời của Mark Rushakoff là tốt, nhưng cá nhân tôi không muốn có để tạo ra những bí danh chỉ để giữ một cú pháp phong cách it -block duy nhất. Vì vậy, sử dụng ví dụ của bạn, nơi mà ban đầu tôi đã viết một mô hình đặc tả như ví dụ của bạn theo hình thức này:

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 

bây giờ tôi sẽ có xu hướng để viết nó thích:

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 

Ý kiến ​​của tôi là tham khảo foo trực tiếp trong expect(foo).to respond_to(:color) là nhiều "trùng lặp" như tham chiếu một subject gián tiếp bằng cách sử dụng it, vì vậy tôi không quá phân đoạn về nó, và tôi nóng lên theo cách mà thông số kỹ thuật expect thường đọc. Nhưng, cuối cùng tôi nghĩ rằng điều này đi xuống chỉ là một vấn đề của phong cách viết ưa thích.