Je pravda ze se hodne pouzivaji na Akceptacni testy, ktere obvykle definuje nekdo jiny nez developer. Ale neznamena to ze nemuzete stejnym spusobem psat unittesty. Oproti unittestum to nema zadnou vyhodu, krome jednoduche citelnosti a toho ze popis/definice testu je i zaklad dokumentace testu a je z nej jasne co je a co neni otestovano (to spousta lidi u unittestu zanedbava).
BDD se používají na jiné úrovni než unit testy a taky je typicky píše někdo jiný z týmu (někdy je upravuje přímo zákazník se znalostí domény). Zatímco unit testy si píšou (ok měli by psát :-) sami vývojáři a jsou součástí běžných změn (v syncu se změnami v kódu), tak BDD scénáře popisují chování systému například na úrovni business logiky.
Ten příklad s add byl blíž k úrovni unit testů (aby se ukázaly základní možnosti jazyka Gherkin), ale názornější budou další příklady založené například na testování REST API nebo web UI se Seleniem. Nebo vůbec obecný popis logiky, který se nijak těsně neváže na kód, ale pouze na očekávané chování.
(tady jsem chtěl napsat příklad, ale byl - nevím proč - vyhodnocen jako spam a nějak jsem nezjistil, které slovo vadí :/)
Pěkně je důvod vzniku BDD popsán přímo na Wikipedii:
https://en.wikipedia.org/wiki/Behavior-driven_development#History