RSpec: açıklama, bağlam, özellik, senaryo?

describe, context, feature, scenario: Ne dört arasında fark (lar) ve yaptığımda her birini kullanmak?

contextİçin bir takma ad describeonlar işlevsel olarak eşdeğer olacak şekilde,. Bunları birbirinin yerine kullanabilirsiniz, tek fark, özellik dosyanızın nasıl okunduğudur. Örneğin test çıktısında bir fark yoktur. RSpec kitabı şöyle diyor:

"Bir describe()şeyler ve context()bağlam için kullanma eğilimindeyiz ".

Şahsen kullanmayı seviyorum describeama insanların neden tercih ettiğini anlayabiliyorum context.

featureve scenarioRSpec'in değil Capybara'nın bir parçasıdır ve kabul testleri için kullanılması amaçlanmıştır. featureeşdeğerdir describe/ contextve scenarioeşdeğer it/ ' example.

Capybara ile kabul testleri yazıyorsanız, feature/ scenariosözdizimi kullanmıyorsanız describe/ itsözdizimini kullanın.

Bu sabah bazı özellikler yazarken aynı soruyu soruyordum. Genellikle bunu kullanıyorum describeve özellikle düşünmüyorum, ancak bu sabah bir modül için birçok durumla ve farklı özelliklerle uğraşıyordum, bu nedenle bu özellikleri okuyacak bir sonraki geliştirici için kolayca anlaşılabilir olması gerekiyordu. Bu yüzden Google'a bunu sordum ve şunu buldum: cevabını oldukça ilginç bulduğum rspec'te bağlama karşı bağlam :

Rspec kaynak koduna göre, "bağlam", yalnızca "açıklama" için bir takma ad yöntemidir, yani bu iki yöntem arasında işlevsel bir fark yoktur. Ancak, her ikisini de kullanarak testlerinizi daha anlaşılır hale getirmenize yardımcı olacak bağlamsal bir fark vardır.

"Tanımlamanın" amacı, bir testler kümesini tek bir işleve göre sarmak, "bağlam" ise bir dizi testi aynı durum altındaki bir işlevle sarmalamaktır.

Yani, bu prensibe dayanarak, şöyle bir özellik yazarsınız:

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

Bunun genel kabul görmüş bir kural olup olmadığından emin değilim, ancak bu yaklaşımı açık ve anlaşılması oldukça kolay buluyorum.

Dokümanlara göre Pierre'in mükemmel cevabını genişletiyor :

DSL özelliği ve senaryosu sırasıyla açıklamak ve buna karşılık gelir. Bu yöntemler, özellik özelliklerinin müşteri ve kabul testleri olarak daha fazla okunmasına izin veren takma adlardır.

Dolayısıyla, Mocha terimlerine aşina olanlar için tanımlayın ve (bir testin davranışını bir kullanıcının bakış açısından tanımlamak için daha uygundur, bu nedenle Mocha öncelikle bir ön uç test çerçevesi olarak işlev görür), şunları yapabilirsiniz:

• her zaman ve sadece kullanmayı seçin describeveit veya başka bir eşlemeyi
• Belirli bir uygulama durumunda birden fazla iddia / test yapılmasını gerektiren itbir contextbloğun içinde kullanmayı seçin

İkinci seçenekle devam edersek, "... aynı durum altındaki bir işleve karşı bir dizi testi [ping] sarma" amacını hala uygulayabilirsiniz.

Dolayısıyla testleriniz şöyle görünebilir:

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

Bu şekilde atlarsınız feature , belirli ön uç özellikler için kullanmak isteyebileceğiniz veya bazıları için rahatsızlık veren FDD (özellik odaklı geliştirme) yapıyorsanız anahtar kelimeyi tamamen atlarsınız. Geliştirici ekibinizden buraya girdi isteyin.

Uyarı: Her zaman endüstri standartlarına uymayın, tüm testlerimizi Volkswagen felsefesine göre modellediğimizi hayal edin?