Pisząc specyfikację w stylu BDD, powinieneś używać „powinien”, czy nie? [Zamknięte]

12

Zdaję sobie sprawę, że jest to nieco subiektywne, ale nie mogę znaleźć dobrego uzasadnienia dla jednego lub drugiego:

„powinien coś zrobić”
to „robi coś”

Zwolennicy stylu powinni wspomnieć, że zmusza cię to do kwestionowania tego, co próbujesz osiągnąć, a przeciwnicy uważają to za zbędne.

Czy istnieje konsensus w tej sprawie, czy jest to wyłącznie kwestia stylu?

Julien
źródło

Odpowiedzi:

3

Witamy w Legal English.

Użycie „powinien” == „powinien” == zobowiązanie umowne. To legalizm. Nie prowadzi to do „przesłuchania”. Oznacza to wyrok jako formalny obowiązek umowny.

Użycie „will” == ”will„ == fajny pomysł. Oznacza to zdanie jako funkcję opcjonalną.

Pytania są częścią ułatwień, organizacji, pomocy, budowania zaufania. Nie jest to ciąg wyboru słowa.

Używanie goły czasownik bez modyfikatora sprawia, że ​​zdanie jest nieco trudniejsze do podkreślenia jako formalny wymóg. A w przypadku czasowników bardzo złożonych, może być trochę ryzykowne, aby dowiedzieć się, jak je skoniugować.

Łatwe - czasowniki takie jak „powiadomić” lub „utworzyć”.

  • System powiadamia przez e-mail. (Czasownik „powiadomić” jest skoniugowany „powiadamia” dla „systemu” - cokolwiek to jest.)

  • System powiadamia za pośrednictwem poczty elektronicznej. („powiadomić” staje się „powiadomi” - bez koniugacji. Bardzo proste.)

Wyrażenia czasownikowe, takie jak „zalogować się” lub wyrażenia czasownikowe specyficzne dla domeny, takie jak „wyodrębnianie, czyszczenie, przekształcanie, deduplikacja i ładowanie” lub rzeczownik taki jak „perspektywa”, który został napisany. Dłuższą frazę, która zawiera kilka czasowników, trudno jest odmienić: odmienić każdy czasownik? A może starasz się koniugować długą frazę tak, jakby to było pojedyncze słowo? Ponieważ każdy rzeczownik może być napisany w języku angielskim, trudno jest wiedzieć, jak odmienić te złożone czasowniki.

  • System wyodrębnia, czyści, przekształca, deduplikuje i ładuje się, gdy użytkownik kliknie Enter. (Angielski w sposób trywialny wymawia dowolną frazę rzeczownika.) A może wyodrębnia, czyści, przekształca, deduplikuje i ładuje?

  • System powinien wyodrębnić, wyczyścić, przekształcić, deduplikować i załadować, gdy użytkownik kliknie Enter. (Ohydna fraza pozostaje nienaruszona, nie ma tajemnicy na temat koniugacji czasownika).

["Co?" mówisz: „jakikolwiek rzeczownik może być napisany w języku angielskim?”. Tak. Dowolny rzeczownik Zamierzam na tym stonewall. Często na tym patrzyłem. Nawet specyfikacje powinny się na tym opierać.]

S.Lott
źródło
5
Mówisz, że użycie „powinien” nie prowadzi do „przesłuchania”; z mojego doświadczenia wynika, że ​​tak jest, szczególnie w przypadku osób początkujących w testowaniu / TDD. Ma również efekt różnicowania wyników od kontekstu i wydarzeń. „I zamówienie dociera do magazynu” nie mówi mi, czy sprawiam, że zamówienie dociera przez naciśnięcie przycisku, czy też powinno to nastąpić automatycznie, podczas gdy „I zamówienie powinno dotrzeć do magazynu” mówi mi, że to powinienem to sprawdzić. BDD dotyczy konwersacji, a nie legalności, angielskiego (lub naturalnego języka z wyboru).
Lunivore,
3
Rozumiem, że masz inny język. BDD zaczęło się jednak w Londynie ... słowem „powinien”;) OP zapytał, czy istnieje konsensus w tej sprawie, a od 2004 r. -> dannorth.net/introducing-bdd
Lunivore
1
Jest to pomysł, że używasz „powinien” w legalny, niekwestionowany sposób, który nie wydaje mi się przydatny. Coś w rodzaju odwrotności umyślnego odkrycia, od którego zaczął BDD. Całe życie staram się pomagać ludziom, którzy zaczynali od „specyfikacji”, a potem czuję, że nie mogą tego kwestionować.
Lunivore
1
Gdybyście zredagowali swoją odpowiedź tak, aby zawierała coś w rodzaju: „Niektórzy lubią„ powinien ”, ponieważ prowadzi to do przesłuchania” zamiast tego, co obecnie mówi, czyli „nie prowadzi do przesłuchania”, byłbym bardzo szczęśliwy. Pytanie dotyczące BDD jest dla mnie jednym z najważniejszych, a sposób, w jaki to sformułowałeś, eliminuje ten aspekt, a nie zapewnia dodatkowego kontekstu. Dziękuję za tę rozmowę, niezależnie od tego, czy edytujesz odpowiedź, czy nie; Naprawdę doceniam pełen szacunku dialog.
Lunivore,
11
IETF standard do pisania RFC wyraźnie stanowi, że „musi” i „zastępuje” są „wymagane”, „powinien” jest „zalecane” i „może” jest „opcjonalne”.
oosterwal 15.03.11
4

Czysto kwestia preferencji stylistycznych. Sprowadza się to do pytania, czy ty / twoi klienci wolicie myśleć o systemie w czasie teraźniejszym czy przyszłym?

Kwalifikatory takie jak „powinien” lub „będą” implikują czas przyszły, ale jest miękki i czyta się wystarczająco dobrze, gdy myślimy w czasie teraźniejszym. Brak kwalifikatora zdecydowanie wskazuje na czas teraźniejszy (tj. Właśnie w tym momencie).

Wolę używać kwalifikatora, ponieważ w obu przypadkach czyta się go dobrze, podczas gdy brak kwalifikatora czyta się nieco dziwnie podczas programowania, gdy wszystko jest w czasie przyszłym.

W każdym razie, jeśli zdecydujesz się użyć kwalifikatora, zdecydowanie zalecamy użycie „musi” zamiast „powinien” . „Powinno” można interpretować jako opcjonalne (pomimo twierdzenia S.Lott, że jest inaczej), ale „musi” całkowicie usuwa wszelką dwuznaczność - musi wyraźnie oznaczać „nieobowiązkowe”.


A ponieważ nie mogę jeszcze komentować (ograniczenia związane z karmą), jest to odpowiedź na S.Lott na temat Powinien / powinienem kontra wola / wola: istnieje wiele niejasności co do woli i woli, nawet przy pisaniu umów prawnych. Wyjaśnienia znajdują się w tym artykule .

Curtis Batt
źródło
„brak kwalifikatora czyta trochę dziwnie podczas programowania, gdy wszystko jest w przyszłości napięte” - cóż, jeśli wykonasz TDD i napisałeś test, ale jeszcze nie napisałeś kodu, test teraz kończy się niepowodzeniem. Podczas gdy semantyka „ma minąć w przyszłości” oznaczałaby, że może przejść TERAZ. Czas teraźniejszy zapewnia większą przejrzystość, przynajmniej w przypadku TDD: nie jest to obietnica dotycząca przyszłości, która zawodzi, lecz zachowanie, którego się oczekuje TERAZ, które nie zachowuje się.
Michaił Vasin
2

Opowiadam się za użyciem trzeciej osoby, czasu teraźniejszego bez kwalifikacji.

Moim głównym argumentem jest to, że: Test to historia.

Historia składa się ze scen. Każda scena opisuje:

  • Przedmiot
  • kontekst
  • akcja

Przykład:

OPIS : getReceiptfunkcja

KONTEKST : paragon istnieje

IT : zwraca paragon

Podobnie jak dobra historia, dobry test jest łatwy do odczytania.

Historia opowiada, co robi program, np

  • rozpoczyna transakcję
  • składa wniosek
  • normalizuje odpowiedź
  • kończy transakcję
  • zwraca paragon

Z drugiej strony użycie kwalifikatora (nie ma znaczenia, czy jest to „powinien” czy „musi”) zamienia test w listę stwierdzeń, np .:

  • powinien rozpocząć transakcję
  • powinien złożyć wniosek
  • powinien znormalizować odpowiedź
  • powinien zakończyć transakcję
  • powinien zwrócić paragon

Nie ma ciągłej historii: twój umysł ocenia listę twierdzeń.

Jest to subiektywne, ale czytanie języka naturalnego (opowieści) jest prostsze niż czytanie listy twierdzeń.

Gajus
źródło
1

Moim zdaniem zawsze powinieneś używać „powinien”.

Rozumowanie - w przypadku BDD, gdy piszesz test, oprogramowanie nie robi jeszcze tego, co chcesz, więc powiedzenie, że „robi coś”, jest fałszywe. „Powinien coś zrobić”, a testy przejdą tak długo, jak będzie to nadal robić.

sevenseacat
źródło
1
Wydaje się, że „jeszcze nie istnieje” jest większym powodem do użycia czasu teraźniejszego zamiast „powinien”. BDD służy do testowania akceptacyjnego, a jeśli system jeszcze czegoś nie robi, powinien natychmiast zawieść. Wydaje się, że istnieje różnica między BDDers, jeśli chodzi o używanie „powinien” lub nie.
Brenden
1

Od behaviour-driven.org zatytułowany "GettingTheWordsRight" :

Krótko mówiąc, słowa, których używamy do opisywania rzeczy, wpływają na sposób, w jaki my (i inni) myślimy o tych rzeczach. To nie jest proste pytanie o bycie małostkowym w związku z semantyką, ponieważ pewne słowa niosą ze sobą niuanse, które wpływają na to, jak interpretujemy znaczenie frazy zarówno na poziomie intelektualnym, jak i emocjonalnym. Nasz język jest bogaty w opisowe słowa i wyrażenia, więc rozsądne wydaje się stosowanie słów, które wyraźnie wyrażą zamiar elementów, które chcemy opisać w kodzie.

W przypadku BDD jestem osobiście, który prawie zawsze używa słowa „ powinien” podczas nazywania testów, ponieważ jego użycie oznacza, że ​​chociaż celem testu jest uzyskanie określonego wyniku, mogą pojawić się inne nieoczekiwane konsekwencje, które trzeba będzie rozwiązać z, jeżeli wynik testu należy uznać za ważny. Możesz użyć słów „ oczekuj lub musisz”podobnie jednak te słowa sugerują bardziej imperatywny punkt widzenia, tak że nazwa testu może zostać pomylona z oznaczeniem „nie ma nic złego w teście, zakładamy, że implementacja została pomieszana”, podczas gdy * powinno „sugerować, że test może być poprawnym, ale może być konieczne ponowne sprawdzenie pod kątem błędów, jeśli wyniki testu nie wydają się sumować. Podoba mi się, ponieważ wpływa to na twoje myślenie, dlatego zachęcasz do zachowania otwartości umysłu podczas pisania kodu, co jest bardzo ważne, jeśli chcesz uniknąć utknięcia podczas próby debugowania kodu i znalezienia się w niewłaściwym miejscu pod kątem błędów z powodu założenia.

Widziałem jednak, że niemal „religijne” zastosowanie tego słowa powinno się nie powieść, gdy zostało ono wymuszone jako przedrostek nazw testowych, ponieważ zmusiło zaangażowanych programistów do przejścia niektórych ćwiczeń gimnastycznych umysłowych i językowych w celu zapewnienia nazwy testowej, która było znaczące, aw takich przypadkach oznaczało, że zamiar poprawnego sformułowania słów nie spełnia jego oczekiwań, a same testy stają się trudne do rozszyfrowania. Kiedy pojawia się taka sytuacja, zwykle używam słowa „ powinien”w dowolnym miejscu w nazwie metody testowej, aby upewnić się, że nazwa przekazuje jej metodę w prosty i jasny sposób. Na pewno jednak nie wymuszałbym użycia określonego słowa, gdyby inne słowa były jednakowo odpowiednie w danym kontekście. Sztuką jest jednak wybranie słów, które nie pozostawiają miejsca na spory o to, co coś reprezentuje w kodzie, i które skłaniają cię do myślenia o tym, co powinien zrobić Twój kod, bez polegania na zwykłej implikacji.

S.Robins
źródło