Mi rendo conto che questo è un po 'soggettivo, ma non riesco a trovare un buon caso per l'uno o l'altro:
it "should do something"
it "does something"
I sostenitori dello stile dovrebbero menzionare 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 è puramente una questione di stile?
Benvenuto in inglese legale.
L'utilizzo di "dovrebbe" == "deve" == l'obbligo contrattuale. È un legalismo. Non porta a "mettere in discussione". Contrassegna la frase come un obbligo contrattuale formale.
Usare "would" == "will" == bella idea. Contrassegna la frase come caratteristica opzionale.
L'interrogatorio fa parte di facilitazione, organizzazione, aiuto, costruzione di fiducia. Non una conseguenza della scelta delle parole.
Utilizzare 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ò essere un po 'azzardato capire come coniugarlo.
Facile: verbi come "notificare" o "creare".
Il sistema notifica via email. (Il verbo "notificare" è coniugato "notifica" per "il sistema" - qualunque cosa sia.)
Il sistema deve avvisare tramite email. ("per notificare" diventa "deve essere notificato" - nessuna coniugazione. Molto semplice.)
Frasi verbali dure come "per accedere" o frasi verbali specifiche del dominio come "per estrarre, ripulire, trasformare, deduplicare e caricare" o un sostantivo come "prospect" che è stato vergato. La frase più lunga che contiene diversi verbi sepolti è difficile da coniugare: coniugare ogni verbo? O prova a coniugare la lunga frase come se fosse una singola parola? Dal momento che qualsiasi nome può essere vergato in inglese, è difficile sapere come coniugare quei verbi inventati.
Il sistema estrae, pulisce, trasforma, deduplica e carica quando l'utente fa clic su Invio. (L'inglese banalmente verbi qualsiasi frase nominale.) 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 è lasciata intatta, nessun mistero sulla coniugazione dei verbi.)
[ "Cosa?" dici, "qualsiasi nome può essere vergato in inglese?". Sì. Qualsiasi nome Sto andando a stonewall su quello. Ho spesso messo le pietre su questo. Anche le specifiche dovrebbero stonewall su quello.]
È puramente una questione di preferenza stilistica. Si riduce a chiedere, i tuoi clienti preferiscono pensare al sistema nel tempo presente o futuro?
Qualificatori come "dovrebbe" o "will" implicano il tempo futuro, ma questo è morbido e si legge abbastanza bene quando si pensa al tempo presente. La mancanza di una qualifica 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 si legge un po 'stranamente durante lo sviluppo quando tutto è futuro.
In ogni caso, se decidi di utilizzare un qualificatore, ti consiglio vivamente di utilizzare "must" invece di "should" . "Should" può essere interpretato come opzionale (nonostante l'affermazione di S.Lott in senso contrario), ma "deve" rimuovere completamente ogni ambiguità - deve chiaramente indicare "non facoltativo".
E poiché non posso ancora commentare (vincoli di karma), questa è una risposta a S.Lott su Dovere / Dovere contro Volontà / Volontà: c'è molta ambiguità su volontà e volontà, anche nella scrittura del contratto legale. Vedi questo articolo per una spiegazione .
Secondo me, dovresti sempre usare 'should'.
Ragionamento: con BDD, quando scrivi il test, il software non ancora fa ciò che vuoi che faccia, quindi dicendo che "fa qualcosa" è falso. "Dovrebbe fare qualcosa", e i test passeranno fintanto che continua a fare quel qualcosa.
Da behaviour-driven.org intitolato "GettingTheWordsRight ":
In breve, le parole che usiamo per descrivere le cose influenzano il modo in cui noi (e altri) pensiamo a queste cose. Non è solo una semplice questione di essere meschini riguardo alla semantica, poiché certe parole portano con sé sfumature che influenzano il modo in cui interpretiamo il significato di una frase sia a livello intellettuale che a livello emotivo. La nostra lingua è ricca di parole e frasi descrittive, quindi sembra ragionevole usare parole che trasmettano chiaramente l'intenzione degli elementi che desideriamo descrivere nel codice.
Nel caso di BDD, sono personalmente chi usa quasi sempre la parola dovrebbe quando si nominano i test, perché il suo uso implica che mentre l'intenzione è che un test fornisca un determinato risultato, altri maggio conseguenze inaspettate che dovranno essere affrontate se un risultato del test deve essere considerato valido. Potresti forse usare le parole expect o devono allo stesso modo, tuttavia queste parole implicano un punto di vista più imperativo tale che il nome del test potrebbe essere interpretato come "non c'è niente di sbagliato con il 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. , perché influenza il tuo pensiero in modo tale che sei incoraggiato a mantenere una mente aperta mentre codifichi, il che è molto importante quando desideri evitare di rimanere bloccato mentre provi a eseguire il debug del codice e ti trovi a cercare nel posto sbagliato gli errori a causa di un'ipotesi.
Tuttavia ho visto che l'applicazione "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 certi aspetti mentali e ginnastica linguistica al fine di fornire un nome di prova che fosse significativo, e in questi casi ha significato che l'intenzione di ottenere le parole giuste non soddisfa le sue aspettative, e gli stessi test diventano difficili da decifrare come un risultato. Quando questo tipo di situazione si verifica, di solito uso la parola dovrebbe in qualsiasi posto all'interno del nome del metodo di test, per garantire che il nome trasmetta il suo metodo in modo semplice e chiaro. Tuttavia, non avrei certamente imposto un particolare uso delle parole se altre parole fossero ugualmente appropriate all'interno di un determinato contesto. Il trucco è comunque quello di scegliere parole che non lasciano spazio a discussioni su ciò che qualcosa rappresenta nel codice, e che ti spingono a pensare alle cose che il tuo codice dovrebbe fare senza fare affidamento su semplici implicazioni.
Sono favorevole all'utilizzo di terza persona, presente senza un qualificatore.
Il mio argomento principale è che: un test è una storia.
Una storia consiste di scene. Ogni scena descrive:
Esempio:
DESCRIBE:
getReceiptfunctionCONTEXT: receipt exists
IT: returns the receipt
Proprio come una buona storia, un buon test è facile da leggere.
Una storia ti dice cosa fa il programma, ad es.
D'altro canto, l'utilizzo di un qualificatore (non importa se è "dovrebbe" o "must") trasforma il test in un elenco di asserzioni, ad esempio:
Non esiste una storia continua: la tua mente sta valutando un elenco di asserzioni.
Questo è soggettivo, ma leggere il linguaggio naturale (una storia) è più semplice della lettura di una lista di asserzioni.