RSpec: mendeskripsikan, konteks, fitur, skenario?

describe, context, feature, scenario: Apa perbedaan (s) antara empat dan kapan saya menggunakan masing-masing?

Itu contextadalah alias untuk describe, jadi secara fungsional setara. Anda dapat menggunakannya secara bergantian, satu-satunya perbedaan adalah cara membaca file spesifikasi Anda. Misalnya, tidak ada perbedaan dalam hasil pengujian. Buku RSpec mengatakan:

"Kami cenderung menggunakan describe()untuk hal-hal dan context()untuk konteks".

Secara pribadi saya suka menggunakan describe, tetapi saya bisa melihat mengapa orang lebih suka context.

featuredan scenariomerupakan bagian dari Kapibara, dan bukan RSpec, dan dimaksudkan untuk digunakan dalam tes penerimaan. featuresetara dengan describe/ context, dan scenariosetara dengan it/ example.

Jika Anda menulis tes penerimaan dengan Capybara, gunakan feature/ scenariosintaks, jika tidak gunakan describe/ itsintaks.

Pagi ini, saat menulis beberapa spesifikasi, saya mengalami pertanyaan yang sama. Biasanya, saya terutama menggunakan describedan tidak terlalu memikirkan hal ini, tetapi pagi ini saya berurusan dengan banyak kasus dan spesifikasi berbeda untuk satu modul, jadi itu harus mudah dipahami oleh pengembang berikutnya yang akan membaca spesifikasi tersebut. Jadi saya bertanya kepada Google tentang ini, dan saya menemukan ini: deskripsikan vs. konteks dalam rspec , yang jawabannya menurut saya cukup menarik:

Menurut kode sumber rspec, "konteks" hanyalah metode alias dari "mendeskripsikan", yang berarti bahwa tidak ada perbedaan fungsional antara kedua metode ini. Namun, ada perbedaan kontekstual yang akan membantu membuat pengujian Anda lebih mudah dipahami dengan menggunakan keduanya.

Tujuan dari "mendeskripsikan" adalah untuk menggabungkan serangkaian pengujian dengan satu fungsionalitas sementara "konteks" adalah untuk menggabungkan serangkaian pengujian terhadap satu fungsionalitas di bawah status yang sama.

Jadi, dengan mengandalkan prinsip ini, Anda akan menulis spesifikasi seperti ini:

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

Tidak yakin apakah ini adalah aturan yang diterima secara umum tetapi saya menemukan pendekatan ini jelas dan cukup mudah dipahami.

Memperluas jawaban bagus Pierre , menurut dokumen :

Fitur dan skenario DSL masing-masing sesuai untuk menggambarkan dan itu. Metode ini hanyalah alias yang memungkinkan spesifikasi fitur untuk dibaca lebih lanjut sebagai tes pelanggan dan penerimaan.

Jadi bagi mereka yang akrab dengan istilah Mocha menggambarkan dan itu (yang lebih cocok untuk menggambarkan perilaku pengujian dari perspektif pengguna, maka Mocha terutama berfungsi sebagai kerangka pengujian front end), Anda dapat:

• memilih untuk selalu dan hanya menggunakan describedan itatau penyandingan lainnya
• memilih untuk menggunakan itdi dalam contextblok yang membutuhkan beberapa pernyataan / pengujian untuk dibuat dalam status aplikasi tertentu

Dengan opsi kedua, Anda masih dapat mengikuti maksud "... membungkus [ping] serangkaian pengujian terhadap satu fungsionalitas dalam status yang sama".

Jadi pengujian Anda mungkin terlihat seperti ini:

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

Dengan cara ini Anda melewatkan featurekata kunci sepenuhnya, yang mungkin ingin Anda gunakan untuk fitur front end tertentu atau jika Anda melakukan FDD (pengembangan yang didorong fitur), yang mungkin terasa tidak nyaman bagi sebagian orang. Mintalah masukan dari tim pengembang Anda di sini.

Peringatan: jangan selalu mengikuti standar industri, bayangkan jika kita mencontoh semua pengujian kita dengan filosofi Volkswagen?