RSpec vs Test :: Unit ใน Rails


15

ฉันไม่เคยมั่นใจในข้อดีที่คุณได้รับจากการเปลี่ยนไปใช้ RSpec จาก Test :: Unit ใน Ruby on Rails (แม้จะอ่านเกี่ยวกับ RSpec เป็นครั้งคราว)

มันเกี่ยวกับ RSpec ที่โครงการ Rails ส่วนใหญ่ดูเหมือนว่าจะใช้หรือไม่

(ตัวอย่างโค้ดบางตัวอย่างที่แสดงให้เห็นข้อดีอย่างชัดเจนของอีกอันหนึ่งจะได้รับการชื่นชมมาก)


4
เพียง 1 ปีต่อมาและฉันดูด้วยความรังเกียจที่ Test :: Unit ... RSpec FTW!
PawełGościcki

ซ้ำซ้อนใกล้กับ StackOverflow: RSpec vs Test :: UnitและRSpec vs. Shoulda
sondra.kinsey

คำตอบ:


13

มันเป็นเรื่องของรสนิยมเป็นส่วนใหญ่และเครื่องมือทดสอบส่วนใหญ่ที่ให้คุณค่ากับการสนับสนุนเกลือทั้งคู่ การตั้งค่าส่วนตัวของฉันสำหรับ RSpec over Test :: Unit เพราะก) เอาต์พุตและเลย์เอาต์ของการทดสอบเน้นไปที่สิ่งที่วัตถุภายใต้การทดสอบควรทำ (ตรงข้ามกับรหัสคืออะไร) และ b) การพูดว่า 'X ควร Y' ทำให้รู้สึกมากกว่าฉัน 'ยืนยันว่า X กริยา Y'

เพื่อให้บริบทบางอย่างสำหรับจุดต่าง ๆ ข้างต้นนี่เป็นการเปรียบเทียบ (เอาท์พุทที่ค่อนข้างดี) ของเอาท์พุท / ซอร์สโค้ดของการทดสอบหน่วยเทียบเท่าสองหน้าที่การทดสอบหนึ่งเขียนโดยใช้ RSpec และอื่น ๆ โดยใช้ Test :: Unit

รหัสภายใต้การทดสอบ

class DeadError < StandardError; end

class Dog
  def bark
    raise DeadError.new "Can't bark when dead" if @dead
    "woof"
  end

  def die
    @dead = true
  end
end

Test :: หน่วย

 require 'test/unit'
  require 'dog'

  class DogTest < Test::Unit::TestCase
    def setup
      @dog = Dog.new
    end

    def test_barks
      assert_equal "woof", @dog.bark    
    end

    def test_doesnt_bark_when_dead
      @dog.die
      assert_raises DeadError do
        @dog.bark
      end
    end
  end

RSpec

require 'rspec'
require 'dog'

describe Dog do
  before(:all) do
    @dog = Dog.new
  end

  context "when alive" do
    it "barks" do
      @dog.bark.should == "woof"
    end
  end

  context "when dead" do
    before do
      @dog.die
    end

    it "raises an error when asked to bark" do
      lambda { @dog.bark }.should raise_error(DeadError)
    end
  end
end

ทดสอบ :: หน่วยผลลัพธ์ (เต็มตามที่ฉันสามารถทำได้)

Ξ code/examples → ruby dog_test.rb --verbose
Loaded suite dog_test
Started
test_barks(DogTest): .
test_doesnt_bark_when_dead(DogTest): .

Finished in 0.004937 seconds.

เอาต์พุต RSpec (ตัวจัดรูปแบบเอกสาร)

Ξ code/examples → rspec -fd dog_spec.rb 

Dog
  when alive
    barks
  when dead
    raises an error when asked to bark

Finished in 0.00224 seconds
2 examples, 0 failures

2 tests, 2 assertions, 0 failures, 0 errors

PS ฉันคิดว่า Berin (ผู้ตอบกลับก่อนหน้านี้) กำลังพูดถึงบทบาทของ Cucumber (ซึ่งงอกออกมาจากโครงการ RSpec แต่เป็นอิสระ) และ RSpec แตงกวาเป็นเครื่องมือสำหรับการทดสอบการยอมรับอัตโนมัติในรูปแบบ BDD ในขณะที่ RSpec เป็นไลบรารีรหัสสำหรับการทดสอบที่สามารถและเป็นที่ใช้ในหน่วยการรวมและระดับการทำงาน ดังนั้นการใช้ RSpec จึงไม่ จำกัด การทดสอบหน่วย - เพียงแค่คุณเรียกว่า 'รายละเอียด' การทดสอบหน่วยของคุณ


ไม่ได้คาดหวังว่าจะรู้สึกเศร้าเมื่อฉันมาที่นี่
โรมัน

3

เมื่อเร็ว ๆ นี้ดูเหมือนว่าแตงกวาได้รับการสนับสนุนเพิ่มเติมในชุมชน Rails นี่คือเหตุผลที่ฉันได้ยินจากการสัมภาษณ์กับนักแสดงนำของ RSpec (จาก Ruby on Rails Podcast)

ในชุมชนที่มีความคล่องตัว (ในขณะนั้น) มีการผลักดันครั้งใหญ่สำหรับการพัฒนาแบบทดสอบที่ขับเคลื่อนด้วยความสำคัญกับการทดสอบก่อนเพื่อพิสูจน์ว่าคุณต้องเปลี่ยนอะไรบางอย่าง มีบางอย่างผิดปกติกับสิ่งนั้น ในสาระสำคัญการทดสอบเป็นวิธีการตรวจสอบว่าการใช้งานของคุณถูกต้องดังนั้นคุณคิดแตกต่างกันอย่างไรเกี่ยวกับการออกแบบการขับขี่ ลูกค้าเป้าหมายของ RSpec สันนิษฐานว่าคุณระบุเป็นอันดับแรกและจะไม่ดีถ้าข้อมูลจำเพาะนั้นตรวจสอบผลลัพธ์ของการใช้งานของคุณหรือไม่

การเปลี่ยนชื่อง่าย ๆassertเพื่อshouldช่วยให้โฟกัสใจในวิธีที่ถูกต้องในการเขียนข้อมูลจำเพาะและคิดถึงการออกแบบ อย่างไรก็ตามนั่นเป็นเพียงส่วนหนึ่งของสมการ

ที่สำคัญกว่านั้นเนื่องจากผู้ที่เชื่อใน TDD หลายคนอ้างว่าการทดสอบเป็นเอกสารในการออกแบบเอกสารส่วนใหญ่ไม่ดีที่สุด การทดสอบค่อนข้างทึบแสงสำหรับผู้ที่ไม่คุ้นเคยกับภาษา ถึงกระนั้นการออกแบบก็ยังไม่ปรากฏชัดเจนจากการอ่านการทดสอบส่วนใหญ่

ดังนั้นในฐานะที่เป็นเป้าหมายรอง RSpec ได้คิดค้นวิธีสร้างเอกสารที่เป็นลายลักษณ์อักษรจากข้อกำหนด นี่เป็นข้อมูลจำเพาะที่เป็นลายลักษณ์อักษรซึ่งทำให้ RSpec ได้เปรียบเหนือ Test :: Unit อย่างง่ายสำหรับการขับเคลื่อนการออกแบบแอปพลิเคชัน เหตุใดจึงต้องเขียนอะไรมากกว่าหนึ่งครั้งเมื่อคุณสามารถจัดทำเอกสารและตรวจสอบความสอดคล้องของการออกแบบในเวลาเดียวกันได้หรือไม่

ความเข้าใจของฉันคือแตงกวาซึ่งมีประโยชน์ในการมาในภายหลังและการเรียนรู้บทเรียนจาก RSpec ทำงานได้ดีขึ้นของเป้าหมายรองนี้โดยไม่สูญเสียเป้าหมายหลัก (ความสามารถในการทดสอบการใช้งานจากข้อกำหนด) แตงกวาทำสิ่งนี้ด้วย API ภาษาอังกฤษที่ค่อนข้างเป็นธรรมซึ่งผู้ที่ไม่ใช่โปรแกรมเมอร์สามารถทำงานอย่างมีเหตุผล พวกเขาอาจต้องการความช่วยเหลือจากโปรแกรมเมอร์เพื่อเติมคำจำกัดความของวิธีการตรวจสอบใหม่ แต่ก็ถูกออกแบบมาให้ขยายได้

บรรทัดล่างคือ RSpec / แตงกวาไม่ควรแทนที่การทดสอบหน่วยทั้งหมด อาจเหมาะสมกว่าการจัดทำเอกสารและตรวจสอบการออกแบบของคุณ - แต่มีการทดสอบการใช้งานหลายอย่างที่ยังต้องทำโดยเฉพาะอย่างยิ่งกับข้อบกพร่องเล็กน้อยที่ได้มาจากการใช้งานและไม่ใช่การออกแบบแอปพลิเคชัน มันลดจำนวนการทดสอบที่คุณต้องเขียน

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.