RSpec: อธิบายบริบทคุณลักษณะสถานการณ์?

describe, context, feature, scenario: ความแตกต่าง (s) ในหมู่ที่สี่คืออะไรและเมื่อฉันจะใช้แต่ละคน?

contextเป็นนามแฝงสำหรับdescribeดังนั้นพวกเขาจะทำงานได้เทียบเท่า คุณสามารถใช้แทนกันได้ข้อแตกต่างเพียงอย่างเดียวคือการอ่านไฟล์ข้อมูลจำเพาะของคุณ ตัวอย่างผลการทดสอบไม่มีความแตกต่างกัน หนังสือ RSpec กล่าวว่า:

"เรามักจะใช้describe()เพื่อสิ่งต่างๆและcontext()เพื่อบริบท"

ส่วนตัวผมชอบที่จะใช้แต่ฉันสามารถดูว่าทำไมคนชอบdescribecontext

featureและscenarioเป็นส่วนหนึ่งของ Capybara ไม่ใช่ RSpec และมีไว้เพื่อใช้สำหรับการทดสอบการยอมรับ featureเทียบเท่ากับdescribe/ contextและscenarioเทียบเท่ากับ/itexample

หากคุณกำลังเขียนการทดสอบการยอมรับด้วย Capybara ให้ใช้feature/ scenariosyntax ถ้าไม่ใช้describe/ itsyntax

เมื่อเช้านี้ในขณะที่เขียนรายละเอียดบางอย่างฉันมีคำถามเดียวกัน โดยปกติแล้วฉันมักจะใช้เป็นหลักdescribeและไม่ได้คิดถึงเรื่องนี้เป็นพิเศษ แต่เมื่อเช้านี้ฉันกำลังจัดการกับเคสมากมายและข้อกำหนดที่แตกต่างกันสำหรับโมดูลเดียวดังนั้นจึงต้องเข้าใจได้ง่ายสำหรับนักพัฒนาคนต่อไปที่จะอ่านข้อกำหนดเหล่านั้น ดังนั้นฉันจึงถาม Google เกี่ยวกับเรื่องนี้และฉันพบสิ่งนี้: อธิบายกับบริบทใน rspecซึ่งคำตอบที่ฉันคิดว่าน่าสนใจมาก:

ตามซอร์สโค้ด rspec "บริบท" เป็นเพียงวิธีนามแฝงในการ "อธิบาย" ซึ่งหมายความว่าไม่มีความแตกต่างในการทำงานระหว่างสองวิธีนี้ อย่างไรก็ตามมีความแตกต่างตามบริบทที่จะช่วยให้การทดสอบของคุณเข้าใจได้ง่ายขึ้นโดยใช้ทั้งสองแบบ

จุดประสงค์ของการ“ อธิบาย” คือการรวมชุดการทดสอบกับฟังก์ชันหนึ่งในขณะที่“ บริบท” คือการรวมชุดการทดสอบกับฟังก์ชันหนึ่งภายใต้สถานะเดียวกัน

ดังนั้นโดยอาศัยหลักการนี้คุณจะต้องเขียนข้อมูลจำเพาะดังนี้:

#
# 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

ไม่แน่ใจว่านี่เป็นกฎที่ยอมรับโดยทั่วไปหรือไม่ แต่ฉันพบว่าแนวทางนี้ชัดเจนและเข้าใจได้ง่าย

ขยายความเกี่ยวกับคำตอบที่ยอดเยี่ยมของปิแอร์ตามเอกสาร :

คุณลักษณะและสถานการณ์จำลอง DSL สอดคล้องกับการอธิบายและตามลำดับ วิธีการเหล่านี้เป็นเพียงนามแฝงที่อนุญาตให้คุณสมบัติคุณสมบัติอ่านเพิ่มเติมในฐานะลูกค้าและการทดสอบการยอมรับ

ดังนั้นสำหรับผู้ที่คุ้นเคยกับคำศัพท์ Mocha จะอธิบายและ (ซึ่งเหมาะกว่าสำหรับการอธิบายพฤติกรรมของการทดสอบจากมุมมองของผู้ใช้ดังนั้น Mocha จึงทำหน้าที่เป็นกรอบการทดสอบส่วนหน้าเป็นหลัก) คุณสามารถ:

• เลือกที่จะใช้เสมอและใช้describeและitหรือการจับคู่อื่น
• เลือกที่จะใช้itภายในcontextบล็อกที่ต้องมีการยืนยัน / การทดสอบหลายรายการในสถานะแอปที่เฉพาะเจาะจง

เมื่อใช้ตัวเลือกที่สองคุณยังคงสามารถทำตามความตั้งใจของ "... ห่อ [ping] ชุดการทดสอบกับฟังก์ชันหนึ่งภายใต้สถานะเดียวกัน"

ดังนั้นการทดสอบของคุณอาจมีลักษณะดังนี้:

#
# 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

ด้วยวิธีนี้คุณจะข้ามfeatureคำหลักทั้งหมดซึ่งคุณอาจต้องการใช้สำหรับคุณลักษณะส่วนหน้าเฉพาะหรือหากคุณกำลังทำ FDD (การพัฒนาที่ขับเคลื่อนด้วยคุณลักษณะ) ซึ่งอาจรู้สึกอึดอัดสำหรับบางคน สอบถามข้อมูลจากทีมนักพัฒนาของคุณที่นี่

ข้อแม้: อย่าทำตามมาตรฐานอุตสาหกรรมเสมอไปลองนึกดูว่าเราจำลองการทดสอบทั้งหมดของเราตามปรัชญาของ Volkswagen หรือไม่?