Me doy cuenta de que esto es algo subjetivo, pero no puedo encontrar un buen caso para uno u otro:
"debería hacer algo"
"hace algo"
Los defensores del estilo deberían mencionar que te obliga a cuestionar realmente qué es lo que estás tratando de lograr, mientras que los detractores lo encuentran simplemente redundante.
¿Existe un consenso sobre esto, o es puramente una cuestión de estilo?
Respuestas:
Bienvenido a Legal English.
El uso de "should" == "deberá" == obligación contractual. Es un legalismo. No conduce a "preguntas". Marca la sentencia como una obligación contractual formal.
Usando "would" == "will" == buena idea. Marca la oración como una característica opcional.
El cuestionamiento es parte de la facilitación, organización, ayuda, construcción de confianza. No es una consecuencia de la elección de palabras.
Usar un verbo simple sin el modificador hace que la oración sea un poco más difícil de resaltar como un requisito formal. Y en el caso de los verbos súper complejos, puede ser un poco complicado descubrir cómo conjugarlo.
Fácil: verbos como "notificar" o "crear".
El sistema lo notifica por correo electrónico. (El verbo "notificar" se conjuga "notifica" para "el sistema", sea lo que sea).
El sistema lo notificará por correo electrónico. ("notificar" se convierte en "notificará" - sin conjugación. Muy simple.)
Frases de verbo duro como "iniciar sesión" o frases de verbo específicas de dominio como "extraer, limpiar, transformar, deduplicar y cargar" o un sustantivo como "prospecto" que ha sido verbalizado. La frase más larga que tiene varios verbos enterrados es difícil de conjugar: ¿conjugar cada verbo? ¿O intentas conjugar la larga frase como si fuera una sola palabra? Dado que cualquier sustantivo puede ser verbalizado en inglés, es difícil saber cómo conjugar esos verbos inventados.
El sistema extrae, limpia, transforma, deduplica y carga cuando el usuario hace clic en Intro. (El inglés verifica trivialmente cualquier frase sustantiva). ¿O se extrae, limpia, transforma, deduplica y carga?
El sistema debe extraer, limpiar, transformar, deduplicar y cargar cuando el usuario hace clic en ingresar. (La horrible frase se deja intacta, no hay misterio sobre la conjugación verbal).
["¿Qué?" usted dice, "cualquier sustantivo puede ser verbalizado en inglés?". Si. Cualquier sustantivo. Voy a hacer un muro de piedra en eso. A menudo me he equivocado con eso. Incluso las especificaciones deberían obstaculizar eso.]
Simplemente una cuestión de preferencia estilística. Todo se reduce a preguntar, ¿prefieren usted / sus clientes pensar en el sistema en tiempo presente o futuro?
Calificadores como "debería" o "voluntad" implica tiempo futuro, pero esto es suave y se lee lo suficientemente bien cuando se piensa en tiempo presente. La falta de un calificador definitivamente indica tiempo presente (es decir, en este momento).
Prefiero usar un calificador porque se lee aceptablemente bien en ambos casos, mientras que la falta de calificador se lee un poco extraño durante el desarrollo cuando todo está en tiempo futuro.
En cualquier caso, si decide usar un calificador, le recomiendo usar "must" en lugar de "should" . "Debería" puede interpretarse como opcional (a pesar de la afirmación de S.Lott de lo contrario), pero "debe" elimina por completo cualquier ambigüedad, debe significar claramente "no opcional".
Y debido a que aún no puedo comentar (restricciones de karma), esta es una respuesta a S.Lott acerca de Does / Shall vs. Would / Will: hay mucha ambigüedad acerca de will y will, incluso en la redacción de contratos legales. Vea este artículo para una explicación .
Estoy a favor de usar una tercera persona, tiempo presente sin un calificador.
Mi argumento principal es que: una prueba es una historia.
Una historia consta de escenas. Cada escena describe:
Ejemplo:
DESCRIBE :
getReceiptfunciónCONTEXTO : existe recibo
IT : devuelve el recibo
Al igual que una buena historia, una buena prueba es fácil de leer.
Una historia te dice lo que hace el programa, por ej.
Por otro lado, el uso de un calificador (no importa si es "debería" o "debe") convierte la prueba en una lista de afirmaciones, por ejemplo:
No hay una historia continua: su mente está evaluando una lista de afirmaciones.
Esto es subjetivo, pero leer el lenguaje natural (una historia) es más simple que leer una lista de afirmaciones.
En mi opinión, siempre debes usar 'should'.
Razonamiento - con TDC, cuando estás escribiendo la prueba, el software no tiene todavía hacer lo que quiere que haga, por lo que dice que "hace algo" es falsa. "Debería hacer algo", y las pruebas pasarán mientras continúe haciendo ese algo.
De behaviour-driven.org titulado "GettingTheWordsRight" :
En resumen, las palabras que usamos para describir las cosas influyen en la forma en que nosotros (y otros) pensamos sobre esas cosas. Esta no es solo una simple cuestión de ser mezquino con la semántica, ya que ciertas palabras llevan consigo matices que afectan la forma en que interpretamos el significado de una frase tanto a nivel intelectual como a nivel emocional. Nuestro lenguaje es rico en palabras y frases descriptivas, por lo que parece razonable usar palabras que transmitan claramente la intención de los elementos que deseamos describir en el código.
En el caso de BDD, soy personalmente quien casi siempre usa la palabra debería cuando nombra las pruebas, porque su uso implica que si bien la intención es que una prueba proporcione un cierto resultado, pueden surgir otras consecuencias inesperadas que deberán tratarse con si un resultado de la prueba se considera válido. Tal vez podría usar las palabras esperar o debede manera similar, sin embargo, estas palabras implican un punto de vista más imperativo, de modo que el nombre de la prueba podría confundirse con "no hay nada malo en la prueba, suponga que la implementación está en mal estado", mientras que * debería "implica que es probable que la prueba ser correcto, pero es posible que deba verificarse nuevamente para ver si hay errores si los resultados de la prueba no parecen sumar. importante cuando desea evitar quedarse atascado cuando intenta depurar su código y se encuentra buscando errores en el lugar equivocado debido a una suposición.
Sin embargo, he visto que la aplicación casi 'religiosa' de la palabra debería fallar cuando se aplica como prefijo para los nombres de las pruebas, ya que ha obligado a los programadores involucrados a pasar por ciertas gimnasias mentales y lingüísticas para proporcionar un nombre de prueba que fue significativo, y en tales casos ha significado que la intención de acertar las palabras no cumple con sus expectativas, y las pruebas en sí mismas se vuelven difíciles de descifrar como resultado. Cuando surge este tipo de situación, normalmente usaría la palabra deberíaen cualquier lugar dentro del nombre del método de prueba, para garantizar que el nombre transmita su método de manera simple y clara. Sin embargo, ciertamente no impondría un uso de palabras en particular si otras palabras fueran igualmente apropiadas dentro de un contexto dado. Sin embargo, el truco consiste en elegir palabras que no dejen espacio para la discusión sobre lo que representa algo en el código, y que lo provoquen a pensar en las cosas que se supone que debe hacer su código sin depender de una mera implicación.