Quando scrivi le specifiche in stile BDD, dovresti usare “should” o no? [chiuso]


12

Mi rendo conto che questo è in qualche modo soggettivo, ma non riesco a trovare un buon caso per l'uno o l'altro:

"dovrebbe fare qualcosa"
, "fa qualcosa"

I sostenitori dello stile dovrebbero menzionare il fatto che ti costringe a mettere in dubbio ciò che stai cercando di ottenere, mentre i detrattori lo trovano semplicemente ridondante.

C'è un consenso su questo, o è semplicemente una questione di stile?

Risposte:


3

Benvenuto in inglese legale.

L'uso di "should" == "deve" == obbligo contrattuale. È un legalismo. Non porta a "domande". Contrassegna la frase come un obbligo contrattuale formale.

Usando "would" == "will" == bella idea. Contrassegna la frase come funzionalità opzionale.

Interrogare fa parte dell'agevolazione, dell'organizzazione, dell'aiuto, della costruzione della fiducia. Non è una conseguenza della scelta delle parole.

L'uso di un verbo nudo senza il modificatore rende la frase leggermente più difficile da evidenziare come requisito formale. E nel caso di verbi super-complessi, può diventare un po 'rischioso capire come coniugarlo.

Facile - verbi come "notificare" o "creare".

  • Il sistema avvisa via e-mail. (Il verbo "notificare" è coniugato "notifica" per "il sistema" - qualunque cosa sia.)

  • Il sistema deve avvisare via e-mail. ("notifica" diventa "notifica" - nessuna coniugazione. Molto semplice.)

Frasi dure come "accedere" o frasi specifiche del dominio come "estrarre, pulire, trasformare, deduplicare e caricare" o un nome come "prospetto" che è stato verbo. La frase più lunga in cui sono sepolti diversi verbi è difficile da coniugare: coniugare ogni verbo? O prova a coniugare la lunga frase come se fosse una sola parola? Dato che qualsiasi sostantivo può essere pronunciato in inglese, è difficile sapere come coniugare quei verbi inventati.

  • Il sistema estrae, pulisce, trasforma, deduplica e carica quando l'utente fa clic su Invio. (In inglese banalmente verbi qualsiasi frase di nome.) Oppure estrae, purifica, trasforma, deduplica e carica?

  • Il sistema dovrebbe estrarre, pulire, trasformare, deduplicare e caricare quando l'utente fa clic su Invio. (La frase orribile rimane intatta, nessun mistero sulla coniugazione del verbo.)

["Che cosa?" dici "qualsiasi nome può essere pronunciato in inglese?". Sì. Qualsiasi nome. Sto andando a Stonewall su questo. Ci ho spesso affrontato questo. Perfino le specifiche dovrebbero essere dure su questo.]


5
Dici che l'uso di "should" non porta a "domande"; la mia esperienza è che lo fa, specialmente con le persone nuove ai test / TDD. Ha anche l'effetto di differenziare i risultati dal contesto e dagli eventi. "E l'ordine arriva al magazzino" non mi dice se sto causando l'arrivo dell'ordine premendo un pulsante, o se dovrebbe avvenire automaticamente, mentre "E l'ordine dovrebbe arrivare al magazzino" mi dice che questo è qualcosa che dovrei controllare. BDD parla di inglese conversazionale, non legale, (o lingua naturale di scelta).
Lunivore,

3
Apprezzo che tu abbia una lingua diversa là fuori. BDD è iniziato a Londra però ... con la parola "dovrebbe";) L'OP ha chiesto se ci fosse un consenso su questo, e ci sono stati dal 2004 -> dannorth.net/introducing-bdd
Lunivore

1
È l'idea che tu usi "dovrebbe" in un modo legale, senza fare domande, che non trovo utile. Un po 'l'opposto della mentalità di scoperta deliberata con cui BDD ha iniziato. Trascorro la mia vita cercando di aiutare le persone che hanno iniziato con "spec" e poi sentono che non possono metterlo in discussione.
Lunivore,

1
Se dovessi modificare la tua risposta in modo che includesse qualcosa del tipo, "Ad alcune persone piace 'dovrebbe' perché porta a domande" invece di ciò che attualmente dice, che è "non porta a domande", sarei molto contento. L'aspetto in discussione di BDD è uno dei più importanti, per me, e il modo in cui lo hai formulato elimina questo aspetto piuttosto che fornire un contesto aggiuntivo. Grazie per questa conversazione, indipendentemente dal fatto che modifichi o meno la risposta; Apprezzo molto il dialogo rispettoso.
Lunivore,

11
Lo standard IETF per la scrittura di RFC afferma specificamente che "DEVE" e "DEVE" sono "NECESSARI", "DOVREBBE" è "CONSIGLIATO" e "MAGGIO" è "FACOLTATIVO".
Oosterwal,

4

È solo una questione di preferenze stilistiche. Si riduce a chiedere, preferisci tu / i tuoi clienti a pensare al sistema al tempo presente o futuro?

Qualificatori come "dovrebbe" o "volontà" implica il tempo futuro, ma questo è morbido e legge abbastanza bene quando si pensa al tempo presente. La mancanza di un qualificatore indica sicuramente il tempo presente (cioè proprio in questo momento).

Preferisco usare un qualificatore perché legge passabilmente bene in entrambi i casi, mentre la mancanza di qualificatore legge un po 'stranamente durante lo sviluppo quando tutto è teso in futuro.

In ogni caso, se decidi di utilizzare un qualificatore, ti consiglio vivamente di utilizzare "must" anziché "should" . "Dovrebbe" può essere interpretato come facoltativo (nonostante l'affermazione di S.Lott al contrario), ma "deve" rimuove completamente qualsiasi ambiguità - deve chiaramente significare "non opzionale".


E poiché non posso ancora commentare (vincoli di karma), questa è una risposta a S. Lott su Dovrebbe / Dovrebbe vs. Volontà / Volontà: c'è molta ambiguità su volontà e volontà, anche nella stesura del contratto legale. Vedi questo articolo per una spiegazione .


"la mancanza di qualificatori legge un po 'stranamente durante lo sviluppo quando tutto è teso in futuro" - beh, se fai TDD e hai scritto un test ma non hai ancora scritto il codice, il tuo test ora fallisce. Mentre la semantica di "dovrebbe passare in futuro" significherebbe che potrebbe passare ADESSO. Quindi il tempo presente porta più chiarezza, almeno nel caso del TDD: non è una promessa sul futuro che fallisce, è il comportamento che ORA si aspetta che non regge.
Mikhail Vasin,

2

Sono favorevole all'utilizzo di terza persona, presente senza un qualificatore.

Il mio argomento principale è che: un test è una storia.

Una storia è composta da scene. Ogni scena descrive:

  • soggetto
  • contesto
  • azione

Esempio:

DESCRIVERE : getReceiptfunzione

CONTESTO : la ricevuta esiste

IT : restituisce la ricevuta

Proprio come una buona storia, un buon test è facile da leggere.

Una storia ti dice cosa fa il programma, ad es

  • inizia una transazione
  • fa una richiesta
  • normalizza la risposta
  • termina la transazione
  • restituisce la ricevuta

D'altra parte, l'uso di un qualificatore (non importa se è "dovrebbe" o "deve") trasforma il test in un elenco di asserzioni, ad esempio:

  • dovrebbe iniziare una transazione
  • dovrebbe fare una richiesta
  • dovrebbe normalizzare la risposta
  • dovrebbero terminare la transazione
  • dovrebbe restituire la ricevuta

Non esiste una storia continua: la tua mente sta valutando un elenco di affermazioni.

Questo è soggettivo, ma leggere il linguaggio naturale (una storia) è più semplice che leggere un elenco di affermazioni.


1

Secondo me, dovresti sempre usare "should".

Ragionamento: con BDD, quando stai scrivendo il test, il software non fa ancora quello che vuoi che faccia, quindi dire che "fa qualcosa" è falso. "Dovrebbe fare qualcosa", e i test passeranno finché continuerà a farlo.


1
"Non esiste ancora" sembra essere una ragione in più per usare il tempo presente invece di "dovrebbe". BDD è per i test di accettazione e se un sistema non fa ancora qualcosa, dovrebbe fallire immediatamente. Sembra esserci una divisione tra i BDDer per quanto riguarda l'uso di "should" o no.
Brenden,

1

Da behaviour-driven.org intitolato "GettingTheWordsRight" :

In breve, le parole che usiamo per descrivere le cose influenzano il modo in cui noi (e gli altri) pensiamo a quelle cose. Questa non è solo una semplice questione di meschinità sulla semantica, poiché alcune parole portano con sé sfumature che influenzano il modo in cui interpretiamo il significato di una frase sia a livello intellettuale che emotivo. Il nostro linguaggio è ricco di parole e frasi descrittive, quindi sembra ragionevole usare parole che trasmettano chiaramente l'intenzione degli elementi che desideriamo descrivere nel codice.

Nel caso del BDD, sono personalmente che quasi sempre uso la parola dovrebbe quando si nominano i test, perché il suo utilizzo implica che mentre l'intenzione è che un test fornisca un certo risultato, possono sorgere altre conseguenze inattese che dovranno essere trattate con se un risultato del test deve essere considerato valido. Potresti forse usare le parole che ti aspetti o che deviallo stesso modo, tuttavia queste parole implicano un punto di vista più imperativo tale che il nome del test potrebbe essere scambiato per significare "non c'è niente di sbagliato nel test, supponiamo che l'implementazione sia incasinata", mentre * dovrebbe "implica che il test è probabile che sia corretto, ma potrebbe essere necessario ricontrollare per errore se i risultati del test non sembrano sommarsi. Mi piace, perché influenza il tuo modo di pensare che sei incoraggiato a tenere una mente aperta mentre scrivi il codice, il che è molto importante quando si desidera evitare di rimanere bloccati mentre si tenta di eseguire il debug del codice e ritrovarsi a cercare errori nel posto sbagliato a causa di un presupposto.

Ho comunque visto che l'applicazione quasi "religiosa" della parola dovrebbe fallire quando è stata applicata come prefisso per i nomi dei test, in quanto ha costretto i programmatori coinvolti a passare attraverso una certa ginnastica mentale e linguistica al fine di fornire un nome di test che era significativo e in tali casi ha significato che l'intenzione di ottenere le parole giuste non soddisfa le sue aspettative e, di conseguenza, i test stessi diventano difficili da decifrare. Quando questo tipo di situazione cresce, di solito userei la parola dovrebbein qualsiasi punto all'interno del nome del metodo di prova, per garantire che il nome trasmetta il suo metodo in modo semplice e chiaro. Certamente non imporrei l'uso di una determinata parola se altre parole fossero ugualmente appropriate in un determinato contesto. Il trucco, tuttavia, è scegliere parole che non lasciano spazio a discussioni su ciò che qualcosa rappresenta nel codice e che ti inducono a pensare alle cose che il tuo codice dovrebbe fare senza fare affidamento sulla semplice implicazione.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.