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.