Lorsque vous rédigez des spécifications de style BDD, devez-vous utiliser «devrait» ou pas? [fermé]


12

Je me rends compte que c'est quelque peu subjectif, mais je ne peux pas trouver un bon cas pour l'un ou l'autre:

il "devrait faire quelque chose"
il "fait quelque chose"

Les partisans du style devrait mentionner qu'il vous oblige à remettre en question ce que vous essayez d'atteindre, tandis que les détracteurs le trouvent simplement redondant.

Y a-t-il un consensus à ce sujet ou s'agit-il uniquement d'une question de style?

Réponses:


3

Bienvenue dans l'anglais juridique.

Utiliser "devrait" == "doit" == obligation contractuelle. C'est un légalisme. Cela ne conduit pas à un "questionnement". Il marque la phrase comme une obligation contractuelle formelle.

Utiliser "would" == "will" == nice idée. Il marque la phrase comme une fonctionnalité facultative.

Le questionnement fait partie de la facilitation, de l'organisation, de l'aide, de l'instauration de la confiance. Pas une conséquence du choix des mots.

L'utilisation d'un verbe nu sans le modificateur rend la phrase légèrement plus difficile à mettre en évidence comme exigence formelle. Et dans le cas des verbes super-complexes, il peut être un peu risqué de comprendre comment le conjuguer.

Facile - des verbes comme "notifier" ou "créer".

  • Le système notifie par e-mail. (Le verbe "notifier" est conjugué "notifie" pour "le système" - quel qu'il soit.)

  • Le système doit informer par e-mail. ("notifier" devient "notifier" - pas de conjugaison. Très simple.)

Hard - expressions verbales comme "se connecter" ou expressions verbales spécifiques au domaine comme "extraire, nettoyer, transformer, dédupliquer et charger" ou un nom comme "perspective" qui a été verbé. La phrase plus longue qui contient plusieurs verbes est difficile à conjuguer: conjuguer chaque verbe? Ou essayez de conjuguer la longue phrase comme s'il s'agissait d'un seul mot? Comme n'importe quel nom peut être verbé en anglais, il est difficile de savoir comment conjuguer ces verbes inventés.

  • Le système extrait, nettoie, transforme, déduplique et charge lorsque l'utilisateur clique sur Entrée. (Les verbes anglais trivialement toute expression nominale.) Ou s'agit-il d'extraire, de nettoyer, de transformer, de dédupliquer et de charger?

  • Le système doit extraire, nettoyer, transformer, dédupliquer et charger lorsque l'utilisateur clique sur Entrée. (La phrase hideuse est laissée intacte, aucun mystère sur la conjugaison des verbes.)

["Quoi?" vous dites, "n'importe quel nom peut être verbé en anglais?". Oui. Tout nom. Je vais faire un mur à ce sujet. J'ai souvent fait des murmures là-dessus. Même les spécifications devraient éviter cela.]


5
Vous dites que l'utilisation de «devrait» ne mène pas à un «questionnement»; mon expérience est que c'est le cas, en particulier avec les personnes novices en test / TDD. Elle a également pour effet de différencier les résultats du contexte et des événements. "Et la commande arrive à l'entrepôt" ne me dit pas si je fais arriver la commande en appuyant sur un bouton, ou si cela doit arriver automatiquement, alors que "Et la commande doit arriver à l'entrepôt" me dit que cela est quelque chose que je devrais vérifier. BDD concerne la conversation, non juridique, l'anglais (ou la langue naturelle de votre choix).
Lunivore

3
J'apprécie que vous ayez un langage différent. Le BDD a commencé à Londres cependant ... avec le mot "devrait";) Le PO a demandé s'il y avait un consensus à ce sujet, et il y a eu depuis 2004 -> dannorth.net/introducing-bdd
Lunivore

1
C'est l'idée que vous utilisez «devrait» d'une manière légale et sans questionnement que je ne trouve pas utile. Un peu à l'opposé de l'état d'esprit de découverte délibéré avec lequel BDD a commencé. Je passe ma vie à essayer d'aider les gens qui ont commencé avec "spec" et puis je sens qu'ils ne peuvent pas remettre en question.
Lunivore

1
Si vous deviez modifier votre réponse afin qu'elle comprenne quelque chose comme, "Certaines personnes aiment" devrait "car cela conduit à des questions" au lieu de ce qu'elle dit actuellement, qui est "cela ne conduit pas à des questions", je serais très content. L'aspect interrogateur du BDD est l'un des plus importants, pour moi, et la façon dont vous l'avez formulé élimine cet aspect plutôt que de fournir un contexte supplémentaire. Merci pour cette conversation, que vous modifiiez ou non la réponse; J'apprécie vraiment le dialogue respectueux.
Lunivore

11
La norme IETF pour la rédaction des RFC stipule spécifiquement que «DOIT» et «DOIT» sont «REQUIS», «DEVRAIT» est «RECOMMANDÉ» et «PEUT» est «FACULTATIF».
oosterwal

4

Purement une question de préférence stylistique. Cela se résume à demander, est-ce que vous / vos clients préférez penser au système au temps présent ou futur?

Les qualificatifs comme «devrait» ou «volonté» impliquent le futur, mais c'est doux et se lit assez bien quand on pense au présent. L'absence d'un qualificatif indique définitivement le présent (c'est-à-dire en ce moment).

Je préfère utiliser un qualificatif car il se lit passablement bien dans les deux cas, alors que le manque de qualificatif se lit un peu étrangement pendant le développement lorsque tout est futur.

Dans tous les cas, si vous décidez d'utiliser un qualificatif, je vous recommande fortement d'utiliser "must" au lieu de "should" . "Devrait" peut être interprété comme étant facultatif (malgré l'affirmation contraire de S.Lott), mais "doit" élimine complètement toute ambiguïté - doit clairement signifier "non facultatif".


Et parce que je ne peux pas encore commenter (contraintes de karma), ceci est une réponse à S.Lott à propos de devrait / doit contre volonté / volonté: il y a beaucoup d'ambiguïté sur le devoir et la volonté, même dans la rédaction d'un contrat légal. Voir cet article pour une explication .


"le manque de qualificatif se lit un peu étrangement pendant le développement quand tout est futur" - eh bien, si vous faites TDD et avez écrit un test mais n'avez pas encore écrit le code, votre test échoue maintenant. Alors que la sémantique de "il est supposé passer dans le futur" signifierait qu'il pourrait passer MAINTENANT. Le présent apporte donc plus de clarté, du moins dans le cas de TDD: ce n'est pas une promesse d'avenir qui échoue, c'est le comportement attendu MAINTENANT qui ne tient pas.
Mikhail Vasin

2

Je suis favorable à l'utilisation d'une troisième personne, au présent sans qualificatif.

Mon principal argument est le suivant: un test est une histoire.

Une histoire se compose de scènes. Chaque scène décrit:

  • matière
  • le contexte
  • action

Exemple:

DESCRIBE : getReceiptfonction

CONTEXTE : le reçu existe

IT : retourne le reçu

Tout comme une bonne histoire, un bon test est facile à lire.

Une histoire vous explique ce que fait le programme, par exemple

  • commence une transaction
  • fait une demande
  • normalise la réponse
  • met fin à la transaction
  • retourne le reçu

D'un autre côté, l'utilisation d'un qualificatif (peu importe qu'il soit "devrait" ou "doit") transforme le test en une liste d'assertions, par exemple:

  • devrait commencer une transaction
  • devrait faire une demande
  • devrait normaliser la réponse
  • devrait mettre fin à la transaction
  • devrait retourner le reçu

Il n'y a pas d'histoire continue: votre esprit évalue une liste d'assertions.

C'est subjectif, mais la lecture du langage naturel (une histoire) est plus simple que la lecture d'une liste d'assertions.


1

À mon avis, vous devriez toujours utiliser «devrait».

Raisonnement - avec BDD, lorsque vous écrivez le test, le logiciel ne fait pas encore ce que vous voulez qu'il fasse, donc dire qu'il "fait quelque chose" est faux. Il "devrait faire quelque chose", et les tests réussiront tant qu'il continuera à faire quelque chose.


1
"N'existe pas encore" semble être une raison de plus d'utiliser le présent au lieu de "devrait". BDD est destiné aux tests d'acceptation et si un système ne fait pas encore quelque chose, il devrait échouer immédiatement. Il semble y avoir un fossé entre les BDD en ce qui concerne l'utilisation de «devrait» ou non.
Brenden

1

De behavior-driven.org intitulé "GettingTheWordsRight" :

En bref, les mots que nous utilisons pour décrire les choses influencent la façon dont nous (et les autres) pensons à ces choses. Ce n'est pas seulement une simple question d'être mesquin sur la sémantique, car certains mots portent avec eux des nuances qui affectent la façon dont nous interprétons le sens d'une phrase à la fois au niveau intellectuel et émotionnel. Notre langage est riche de mots et de phrases descriptives, il semble donc raisonnable d'utiliser des mots qui traduisent clairement l'intention des éléments que nous souhaitons décrire dans le code.

Dans le cas de BDD, je suis personnellement celui qui utilise presque toujours le mot devrait lors de la dénomination des tests, car son utilisation implique que, bien que l'intention soit qu'un test fournisse un certain résultat, d'autres conséquences inattendues peuvent survenir et devront être traitées. avec si un résultat de test doit être considéré comme valide. Vous pourriez peut-être utiliser les mots attendre ou devoirde la même manière, cependant, ces mots impliquent un point de vue plus impératif, de sorte que le nom du test pourrait être confondu avec «il n'y a rien de mal avec le test, supposons que la mise en œuvre est foirée», tandis que * devrait «implique que le test est susceptible de être correct, mais il peut être nécessaire de vérifier à nouveau s'il y a une erreur si les résultats du test ne semblent pas s'additionner. J'aime cela, car cela influence votre façon de penser de sorte que vous êtes encouragé à garder l'esprit ouvert lorsque vous codez, ce qui est très important lorsque vous souhaitez éviter de rester bloqué lorsque vous essayez de déboguer votre code et que vous vous retrouvez à chercher des erreurs au mauvais endroit en raison d'une hypothèse.

J'ai cependant vu que l'application quasi «religieuse» du mot devrait échouer lorsqu'il a été appliqué en tant que préfixe pour les noms de test, car il a forcé les programmeurs impliqués à passer par une gymnastique mentale et linguistique afin de fournir un nom de test qui était significatif, et dans de tels cas, cela signifiait que l'intention de bien prononcer les mots ne répond pas à ses attentes, et les tests eux-mêmes deviennent difficiles à déchiffrer en conséquence. Lorsque ce genre de situation survient, j'utilisais généralement le mot devraità n'importe quel endroit du nom de la méthode de test, pour garantir que le nom transmet sa méthode simplement et clairement. Cependant, je n'appliquerais certainement pas un mot particulier si d'autres mots étaient également appropriés dans un contexte donné. L'astuce consiste cependant à choisir des mots qui ne laissent aucune place à l'argumentation sur ce que quelque chose représente dans le code, et qui vous incitent à penser aux choses que votre code est censé faire sans se fier à une simple implication.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.