W jaki sposób rozwój oparty na zachowaniach poprawia przejrzystość, gdy języki naturalne są niejednoznaczne?

Obecnie badam frameworki testowe BDD , takie jak ogórek, i ciekawe, kiedy ludzie mówią

ponieważ pliki funkcji są w prostym języku naturalnym, poprawia to przejrzystość i daje wyraźną wizję

ale czy język naturalny nie jest przyczyną większości problemów, jakie mamy w inżynierii oprogramowania?

Język naturalny jest niejednoznaczny i dlatego wiele projektów oprogramowania kończy się niepowodzeniem z powodu błędnej interpretacji wymagań klientów i zrozumienia przez programistę. Nie rozumiem niszę tutaj.

Tak, podział testów na małe, proste, wykonalne czynności ma sens i daje pewien poziom przejrzystości, ale czy to poprawia produktywność w ogóle?

PS: Nie jestem ekspertem i nie wypowiadam się tutaj. Jestem tylko ciekawy, aby zrozumieć tę koncepcję.

Masz rację. BDD nie eliminuje problemów z niejednoznacznością języka - wcale. Jak zauważyli inni, przetłumaczone fragmenty należy dopasować, odpowiednio je definiując, ale nie rozwiązuje to również problemu leżącego u podstaw niejednoznaczności.

Dlaczego warto BDD, mimo że nie rozwiązał tego problemu? Jest kilka powodów i ta lista z pewnością nie jest kompletna.

Niejednoznaczność nie została rozwiązana

To nie jest ani powód na korzyść BDD, ani przeciw. Ale kiedy porównasz to z innymi podejściami, takimi jak historie użytkowników lub wymagania, wtedy wszystkie podejścia do programowania SW mają dwuznaczność językową, ponieważ wszystkie zaczynają się w taki czy inny sposób od sformułowania w języku naturalnym.

Technicznie problem dwuznaczności językowej został rozwiązany w przypadku języków sztucznych, takich jak lojban , ale z drugiej strony klient i programiści najprawdopodobniej nie znają tego języka.

Wszechobecny język

BDD idzie w parze z ideą wszechobecnego języka. Możliwość określenia scenariuszy wraz ze wszystkimi klientami, testerami i programistami daje BDD przewagę nad innymi metodami.

Rozważ tradycyjnego inżyniera wymagań spisującego wszystkie wymagania. Gdy jako tester lub klient zdobędziesz ten 300-stronicowy dokument pełen wymagań do przejrzenia, będziesz miał o wiele więcej palących problemów niż stosowana tam terminologia.

Historie użytkowników radzą sobie nieco lepiej na tym froncie, ponieważ uwzględniają również wszystkie zainteresowane strony w ich tworzeniu. Jeśli chodzi o wszechobecny język, nie powiedziałbym, że BDD lub historie użytkowników są lepsze - choć różnią się znacznie w następnym punkcie.

Testowalność

Głównym aspektem BDD jest to, że twoje specyfikacje są w rzeczywistości wykonywalne (przez Cucumber lub tym podobne). Ani wymagania, ani historie użytkowników nie oferują tej funkcji. Dla mnie osobiście jest to główny punkt sprzedaży BDD.

Porównaj to z tradycyjnymi wymaganiami - od wieków informowaliśmy inżynierów wymagań, że ich wymagania powinny być możliwe do przetestowania. Jednak każdy projekt ma przypadek, w którym gdzieś na dole testerzy zdają sobie sprawę, że nie mają pojęcia, jak przetestować określone wymagania.

Historie użytkowników, jeśli są odpowiednio wykonane, obejmują testerów na wczesnym etapie tworzenia, aby się upewnić. Niestety jest to przypadek zderzenia teorii z prawdziwym światem, w którym widziałem wiele historii, których żaden tester wcześniej nie widział.

Z drugiej strony BDD automatycznie daje ci testowy scenariusz. Nie ma wymówek i nie można tego obejść (no chyba, że ​​całkowicie zignorujesz warstwy automatyzacji i po prostu napiszesz scenariusze dla fantazyjnej poezji).

Mówiąc bardziej ogólnie, Test First jest zasadą, która była bardzo satysfakcjonująca na wszystkich etapach rozwoju oprogramowania, a BDD jest jego zastosowaniem do najbardziej zewnętrznej warstwy rozwoju (w porównaniu np. TDD na poziomie jednostki).

Podsumowanie

Podsumowując, BDD nie podnosi cię z problemów niejednoznaczności języka naturalnego. Pomaga to jednak rozwiązać ten problem poprzez dwa ważne punkty: Koncentrowanie się na wszechobecnym języku w celu zmniejszenia dwuznaczności (nie wyeliminuje ich całkowicie, ale pomaga tonie!) I zmuszając cię do napisania pliku wykonywalnego specyfikacje. Ten ostatni punkt pomaga rozwiązać problemy niejednoznaczności, głównie dlatego, że w tym przypadku niejasności zaczynają pojawiać się jako problemy.

Kiedy coś jest napisane w „języku naturalnym”, może to oznaczać wiele rzeczy:

• To jest dosłownie angielski. Ponieważ angielski jest bardzo dwuznacznym i nieprecyzyjnym językiem, ten tryb wprowadzania danych jest niezadowalający w kontekście rozwoju oprogramowania.

• To jest angielski, ale odpowiednie terminy są dokładnie zdefiniowane. Taki język jest używany w dokumentach prawnych lub tekstach matematycznych.

• Jest to język formalny, ale modeluje się go bardzo ściśle według konwencji języka naturalnego. W pewnym stopniu opisuje wszystkie języki programowania. Im bardziej język formalny jest podobny do angielskiego, tym łatwiej jest go zrozumieć nieprzeszkolonym czytelnikom. Godne uwagi przykłady języków programowania z tym celem to COBOL i SQL: select id, name from persons where age > 18jest natychmiast oczywiste. Wadą tych języków jest to, że musisz znać język formalny, aby pisać działający kod. Ponadto te języki są często bardzo gadatliwe.

DDD sugeruje, że projekt używa wszechobecnego języka do opisania domeny. Jest to zasadniczo przypadek 2: zdefiniuj odpowiednie terminy, abyś mógł precyzyjnie komunikować się w języku naturalnym.

Sam ogórek to przypadek 3: język formalny, którego intencją jest czytanie bardzo zbliżone do normalnego języka angielskiego. Mówiąc dokładniej: Cucumber to framework, który pozwala zdefiniować prosty język formalny, którego można użyć do wyrażenia wymagań / testów. Chodzi o to, że ten sam dokument reprezentuje wymagania języka naturalnego i automatycznie wykonywane testy, więc oba będą zawsze zsynchronizowane. Możesz przeczytać scenariusz ogórka i sprawdzić, czy poprawnie wyraża on twoje wymaganie, bez konieczności rozumienia, jak to wszystko działa.

Ogórek działa poprzez dopasowanie dokumentu do znanych fragmentów języka naturalnego. Te fragmenty należy najpierw zdefiniować. Aby napisać scenariusz w Cucumber, musisz wiedzieć o dostępnych fragmentach - oprogramowanie nie odczyta twoich myśli. Te fragmenty są również źródłem możliwych problemów: po zaimplementowaniu zachowania fragmentu tekstu kod może zrobić coś nieco innego niż sugeruje tekst fragmentu. Jest mało prawdopodobne, aby stanowił problem, jeśli ten sam fragment kodu jest używany wiele razy. Ogórek nadaje się zatem doskonale do opisywania reguł biznesowych, które składają się z mniejszego zestawu warunków, działań i wyników. Inne ramy testowe mogłyby być lepsze, gdyby każdy fragment był używany tylko raz lub dwa razy, np. Ponieważ konfiguracja dla każdego przypadku testowego jest unikalna.

@ Raghuram8892, tekst po słowach kluczowych Podane / Kiedy / Wtedy / I musi pasować do „fragmentu”, w przeciwnym razie krok nie powiedzie się jako niezdefiniowany lub „w toku”. Jako taki wpada wprost w przypadek 3.

Jeśli chodzi o „angielski”, ogórek i jego język, korniszon są przeznaczone do użytku międzynarodowego. Możesz wywołać to polecenie, cucumber --i18n helpaby wyświetlić listę aktualnie obsługiwanych języków i cucumber --i18n $CODEsłowa kluczowe dla określonego kodu języka. Na przykład cucumber --i18n eopodaje słowa kluczowe dla esperanto.