Come eseguire BDD con GWT utilizzando MSpec?Il modo corretto di scrivere questo scenario

Question

Sto appena iniziando a esercitarmi in BDD utilizzando l'approccio GWT per il seguente esercizio di codice e mi sono appena reso conto che non posso eseguire il secondo test.

Il mio GWT fa qualcosa del genere

Given there exists an open query
When the user replies to the query
Then it should save the reply if the reply is not blank

Quindi dovrebbe avvisare l'utente e non salvare la risposta se è vuota

Quindi l'ho codificato in questo modo

public class when_user_replies_to_the_query : OpenQuery
{
    Because
    {
         query.Reply(data);
    }

    ThenIt should_save_the_reply_to_the_database_if_there_is_a_reply

    ThenIt should_notify_the_user_if_there_is_no_text_in_the_reply_and_not_save_to_database
}

public class Query
{
    void Reply(string data)
    {
        //do something
    }
}

Ma poi mi sono reso conto che non posso fare il secondo caso perché il primo caso richiede che i dati contengano qualcosa mentre il secondo caso dice che i dati dovrebbero essere una stringa vuota.

Questo significa che dovrei dividere il mio GWT in qualcosa di simile

Given the reply is blank
When the user replies to the query
Then it should notify the user ......

Se questo è il caso, scriverei un'enorme quantità di scenari nulli per la restituzione

values being null. Such as
Given the database is null
When retrieving queries
Should reply with error message
When saving queries
Should save to file and reply with error message
When // basically doing anything
Should //give appropriate response

È così che dovrei scrivere le mie specifiche BDD?E sono nel forum giusto O_O?

Answer 1

Vorresti invertire le due cose Then clausole, perché fondamentalmente formano contesti diversi in cui il Query la lezione viene esercitata.Quando li leggi entrambi Then affermazioni puoi vedere che "se non è vuoto" e "è vuoto" formano entrambi i contesti.

1. Contesto n. 1:

   Given an open query
   Given a non-blank reply
   When the user replies to the query
   It should save the reply
   
   public class When_the_user_replies_to_the_query_and_the_reply_is_not_blank
   {
      static Query Query;
   
      Establish context = () =>
      {
          Query = new Query();
      };
   
      Because of = () =>
      {
          Query.Reply("answer");
      };
   
      It should_save_the_reply = () =>
      {
          // Use your imagination
      };
   }
   

2. Contesto n. 2:

   Given an open query
   Given a blank reply
   When the user replies to the query
   It should not save the reply
   It should notify the user
   
   public class When_the_user_replies_to_the_query_and_the_reply_is_blank
   {
      static Query Query;
   
      Establish context = () =>
      {
          Query = new Query();
      };
   
      Because of = () =>
      {
          Query.Reply(String.Empty);
      };
   
      It should_not_save_the_reply = () =>
      {
          // Use your imagination
      };
   
      It should_notify_the_user = () =>
      {
          // Use your imagination
      };
   }
   

Considerando che potresti avere più possibili valori di "risposta vuota" (null, String.Empty, " ", \r\n), potresti scrivere contesti per ognuno di questi.Spesso non scrivo specifiche per qualsiasi combinazione immaginabile di valori, ma piuttosto

• avere un contesto per il "percorso felice", cioèla risposta non è vuota
• avere un contesto per le risposte vuote

Alla luce del tuo esempio, si potrebbe sostenere che il Query class non è il posto giusto per decidere se una risposta soddisfa la specifica "non è vuota".Dovresti piuttosto codificare quella decisione in una classe separata e il Query dovrebbe fare affidamento sulla decisione di quello.Ciò porterebbe alcuni vantaggi:

• Separazione degli interessi:IL Query la classe e la specifica possono evolversi separatamente
• Puoi riutilizzare la specifica in più posti, suggerendo un problema con la risposta prima che l'utente pubblichi la sua risposta vuota
• È possibile ottenere la specifica in prova separatamente senza preoccuparsi della notifica dell'utente e dei salvataggi nel database, evitando così l'esplosione del contesto Query preoccupazioni