Sự khác nhau giữa RSpec và Cucumber là gì?

Question

Tôi có 6 tháng kinh nghiệm phát triển Rails. Tôi đã xây dựng một ứng dụng web hiện đang được sử dụng với xác thực và ủy quyền và db postgresql.

Tôi đang chuyển sang ứng dụng Rails thứ hai nhưng lần này, sau các bài học, tôi muốn phát triển nó bằng TDD, vì tôi nhận thấy nó dễ dàng hơn nhiều để mở rộng và sửa lỗi. Nó phát triển chậm nhưng trong thời gian dài nó dễ dàng hơn nhiều để đối phó với.

Tôi đã nghe nói về Rspec và dưa chuột nhưng hoàn toàn bị nhầm lẫn bởi chúng.

Tôi muốn biết sự khác nhau giữa RSpec và Cucumber là gì và chúng được sử dụng để làm gì. Nó cũng sẽ hữu ích nếu biết, từ quan điểm của một người mới bắt đầu (cũng là nhà phát triển duy nhất) cho dù một khuôn khổ thử nghiệm là thực sự cần thiết.

Answer 1

RSpec và dưa chuột là cả hai khung kiểm tra. RSpec bao gồm Kiểm thử Đơn vị truyền thống (có nghĩa là kiểm tra một lớp hoặc một phần của ứng dụng trong sự cô lập với phần còn lại của ứng dụng. Vì vậy, mô hình của bạn thực hiện những gì mà mô hình của bạn phải làm, bộ điều khiển thực hiện những gì nó được yêu cầu, vv).

RSpec và dưa chuột đều được sử dụng để kiểm tra chấp nhận (được gọi là ATDD, BDD, đặc điểm kỹ thuật bằng ví dụ, v.v. tùy thuộc vào người bạn yêu cầu). Đây là các thử nghiệm tích hợp theo trường hợp kinh doanh, có nghĩa là chúng mô phỏng cách người dùng sử dụng ứng dụng và sử dụng ngăn xếp Rails đầy đủ để các vấn đề về cách các phần khác nhau của ứng dụng hoạt động cùng nhau. tìm thấy.

Sự khác biệt chính giữa RSpec và Cucumber là yếu tố dễ đọc của doanh nghiệp. Điểm thu hút chính của Cucumber là đặc điểm kỹ thuật (tính năng) tách biệt với mã kiểm tra, do đó, chủ sở hữu sản phẩm của bạn có thể cung cấp hoặc xem lại đặc điểm kỹ thuật mà không cần phải tìm hiểu mã. Đây là các tệp .feature mà bạn tạo trong Cucumber. RSpec có một cơ chế tương tự, nhưng thay vào đó bạn mô tả một bước với một mô tả, bối cảnh hoặc khối có chứa đặc tả nghiệp vụ, và sau đó ngay lập tức có mã thực hiện câu lệnh đó. Cách tiếp cận này là dễ dàng hơn một chút đối với các nhà phát triển để làm việc với nhưng một chút khó khăn hơn cho những người không phải kỹ thuật.

Để sử dụng? Nếu bạn là nhà phát triển và chủ sở hữu sản phẩm duy nhất, thì tôi sẽ gắn bó với RSpec, tôi cảm thấy dễ hiểu hơn với người kĩ thuật, cung cấp một vài lợi thế trong việc giữ cho mọi thứ bị kiểm soát và kiểm soát, đồng thời giúp bạn thoát khỏi RegExs để kiểm tra các bước. Nếu bạn đang xây dựng điều này cho một khách hàng, và họ là thực hành liên quan đến các đặc điểm kỹ thuật, đi với dưa chuột cho thử nghiệm chấp nhận của bạn và sử dụng RSpec cho bài kiểm tra đơn vị.

Chỉ cần để chứng minh sự khác biệt chính giữa hai:

Dưa chuột:

#articles.feature 
Given an article exists called "Testing Demonstration" 
When I visit the list of articles 
Then I should see an article called "Testing Demonstration" 

#article_steps.rb 
Given /^an article exists called "(.+)"$/ do |title| 
    FactoryGirl.create(:article, title: title) 
end 
When /^I visit the list of articles$/ do 
    visit articles_path 
end 
Then /^I should see an article called "(.+)"$/ do |title| 
    page.should have_content title 
end 

RSpec

describe "Articles" do 
    let(:article) { FactoryGirl.create(:article) } 
    context "Index Page" do 
    before { visit articles_path } 
    it { page.should have_content article.title } 
    end 
end 

loạt blog này là tuyệt vời vào nhận đi với RSpec: http://everydayrails.com/2012/03/12/testing-series-intro.html