RSpec: mô tả, bối cảnh, tính năng, kịch bản?

describe, context, feature, scenario: Phần chênh lệch (s) giữa bốn là gì và khi nào tôi sử dụng mỗi người?

Là contextmột bí danh cho describe, vì vậy chúng tương đương về mặt chức năng. Bạn có thể sử dụng chúng thay thế cho nhau, sự khác biệt duy nhất là cách đọc tệp đặc tả của bạn. Ví dụ, không có sự khác biệt trong đầu ra thử nghiệm. Sách RSpec nói:

"Chúng ta có xu hướng sử dụng describe()cho những thứ và context()cho ngữ cảnh".

Cá nhân tôi thích sử dụng describe, nhưng tôi có thể hiểu tại sao mọi người lại thích context.

featurevà scenariolà một phần của Capybara, không phải RSpec, và được sử dụng cho các bài kiểm tra chấp nhận. featuretương đương với describe/ contextvà scenariotương đương với it/ example.

Nếu bạn đang viết các bài kiểm tra chấp nhận với Capybara, hãy sử dụng cú pháp feature/ scenario, nếu không sử dụng cú pháp describe/ it.

Sáng nay, trong khi viết một số thông số kỹ thuật, tôi đã có cùng một câu hỏi. Thông thường, tôi chủ yếu sử dụng describevà không đặc biệt nghĩ về điều này, nhưng sáng nay tôi đã xử lý rất nhiều trường hợp và các thông số kỹ thuật khác nhau cho một mô-đun, vì vậy nó phải dễ hiểu đối với nhà phát triển tiếp theo sẽ đọc các thông số kỹ thuật đó. Vì vậy, tôi đã hỏi Google về điều này và tôi tìm thấy điều này: mô tả so với ngữ cảnh trong rspec , câu trả lời mà tôi thấy khá thú vị:

Theo mã nguồn rspec, “context” chỉ là một phương thức bí danh của “description”, nghĩa là không có sự khác biệt về chức năng giữa hai phương thức này. Tuy nhiên, có một sự khác biệt về ngữ cảnh sẽ giúp làm cho các thử nghiệm của bạn dễ hiểu hơn bằng cách sử dụng cả hai.

Mục đích của "description" là bao bọc một tập hợp các thử nghiệm đối với một chức năng trong khi "ngữ cảnh" là bao bọc một tập hợp các thử nghiệm đối với một chức năng trong cùng một trạng thái.

Vì vậy, dựa trên nguyên tắc này, bạn sẽ viết một thông số kỹ thuật như sau:

#
# The feature/behaviour I'm currently testing
#
describe "item ordering" do
  
  # 1st state of the feature/behaviour I'm testing
  context "without a order param" do
    ...
  end

  # 2nd state of the feature/behaviour I'm testing
  context "with a given order column" do
    ..
  end

  # Last state of the feature/behaviour I'm testing
  context "with a given order column + reverse" do
    ..
  end
end

Không chắc liệu đây có phải là quy tắc được chấp nhận chung hay không nhưng tôi thấy cách tiếp cận này rõ ràng và khá dễ nắm bắt.

Mở rộng câu trả lời xuất sắc của Pierre , theo tài liệu :

Tính năng và kịch bản DSL tương ứng với mô tả và nó, tương ứng. Các phương pháp này chỉ đơn giản là bí danh cho phép các thông số kỹ thuật của tính năng đọc nhiều hơn dưới dạng các bài kiểm tra chấp nhận và khách hàng.

Vì vậy, đối với những người quen thuộc với các thuật ngữ Mocha mô tả và nó (phù hợp hơn để mô tả hành vi của thử nghiệm từ góc độ người dùng, do đó Mocha chủ yếu hoạt động như một khung thử nghiệm giao diện người dùng), bạn có thể:

• chọn luôn luôn và chỉ sử dụng describevà ithoặc ghép nối khác
• chọn sử dụng itbên trong một contextkhối yêu cầu nhiều xác nhận / thử nghiệm được thực hiện trong một trạng thái ứng dụng cụ thể

Với tùy chọn thứ hai, bạn vẫn có thể thực hiện theo ý định "... bọc [ping] một tập hợp các bài kiểm tra đối với một chức năng trong cùng một trạng thái".

Do đó, các bài kiểm tra của bạn có thể trông như thế này:

#
# The feature/behaviour I'm currently testing
#
describe "item ordering" do

  # 1st state of the feature/behaviour I'm testing
  context "without an order param" do
    # 1st and only test we want to run in this state
    it "asks the user for missing order param" do
     ...
    end
  end

  # 2nd state of the feature/behaviour I'm testing
  context "with an invalid order param" do
    # 1st test we want to run in this state
    it "validates and rejects order param" do
      ...
    end
    # 2nd test we want to run in this state
    it "returns an error to user" do
      ...
    end
  end

  # 3rd state of the feature/behaviour I'm testing with multiple tests
  context "with a valid order param" do
    it "validates and accepts order param" do
      ...
    end
    it "displays correct price for order" do
      ...
    end
    unless being_audited
      it "secretly charges higher price to user" do
        ...
      end
    end
  end
end

Bằng cách này, bạn bỏ qua featurehoàn toàn từ khóa mà bạn có thể muốn sử dụng cho các tính năng giao diện người dùng cụ thể hoặc nếu bạn đang thực hiện FDD (phát triển theo hướng tính năng), điều này có thể cảm thấy không thoải mái đối với một số người. Yêu cầu nhóm nhà phát triển của bạn cho ý kiến ​​tại đây.

Lưu ý: không phải lúc nào cũng tuân theo các tiêu chuẩn công nghiệp, hãy tưởng tượng nếu chúng tôi mô phỏng tất cả các thử nghiệm của mình theo triết lý Volkswagen?