RSpec: descrivere, contesto, funzionalità, scenario?

describe, context, feature, scenario: Qual è la differenza (s) tra i quattro e quando devo utilizzare ciascuno di essi?

Il contextè un alias per describe, quindi sono funzionalmente equivalenti. Puoi usarli in modo intercambiabile, l'unica differenza è come legge il tuo file delle specifiche. Ad esempio, non c'è differenza nell'output di prova. Il libro RSpec dice:

"Tendiamo a usare describe()per le cose e context()per il contesto".

Personalmente mi piace usare describe, ma posso capire perché le persone preferiscono context.

featuree scenariofanno parte di Capybara, e non di RSpec, e devono essere utilizzati per i test di accettazione. featureè equivalente a describe/ contexted è scenarioequivalente a it/ example.

Se stai scrivendo test di accettazione con Capybara, usa la sintassi feature/ scenario, altrimenti usa la sintassi describe/ it.

Questa mattina, mentre scrivevo alcune specifiche, avevo la stessa domanda. Di solito lo uso principalmente describee non ci penso particolarmente, ma questa mattina avevo a che fare con molti casi e specifiche diverse per un modulo, quindi doveva essere facilmente comprensibile per il prossimo sviluppatore che leggerà quelle specifiche. Quindi ho chiesto a Google informazioni su questo, e ho trovato questo: Descrivi vs. contesto in rspec , la cui risposta trovo piuttosto interessante:

Secondo il codice sorgente rspec, "contesto" è solo un metodo alias di "descrizione", il che significa che non vi è alcuna differenza funzionale tra questi due metodi. Tuttavia, esiste una differenza contestuale che ti aiuterà a rendere i tuoi test più comprensibili utilizzando entrambi.

Lo scopo di "descrivere" è racchiudere un insieme di test in una funzionalità mentre "contesto" è avvolgere un insieme di test in una funzionalità nello stesso stato.

Quindi, basandosi su questo principio, scriveresti una specifica come questa:

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

Non sono sicuro che questa sia una regola generalmente accettata, ma trovo questo approccio chiaro e abbastanza facile da comprendere.

Espandendo l' eccellente risposta di Pierre , secondo i documenti :

La funzione e lo scenario DSL corrispondono rispettivamente a descrivere e esso. Questi metodi sono semplicemente alias che consentono alle specifiche delle funzionalità di leggere di più come test del cliente e di accettazione.

Quindi, per chi ha familiarità con i termini Mocha che descrivono e (che sono più adatti a descrivere il comportamento di un test dal punto di vista dell'utente, quindi Mocha funziona principalmente come framework di test front-end), potresti:

• scegliere di utilizzare sempre e solo describeeit o in un altro accoppiamento
• scegliere di utilizzare itall'interno di un contextblocco che richiede più asserzioni / test da effettuare in uno stato specifico dell'app

Andando con la seconda opzione, puoi ancora seguire l'intenzione di "... racchiudere [ping] una serie di test su una funzionalità nello stesso stato".

Quindi i tuoi test potrebbero assomigliare a questo:

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

In questo modo salti il ​​file feature parola chiave, che potresti voler utilizzare per specifiche funzionalità di front-end o se stai facendo FDD (sviluppo guidato dalle funzionalità), che potrebbe essere scomodo per alcuni. Chiedi al tuo team di sviluppatori un input qui.

Avvertenza: non seguite sempre gli standard del settore, immaginate se modellassimo tutti i nostri test sulla filosofia Volkswagen?