Ты прав. BDD не устраняет проблемы с языковой неоднозначностью - совсем нет. Как указывали другие, переводимые фрагменты должны быть сопоставлены путем правильного их определения, но это также не решает основную проблему неоднозначности.
Теперь, почему BDD действительно стоит, несмотря на то, что эта проблема не решена? Есть несколько причин, и этот список, конечно, не полный.
Неоднозначность не была решена
Это не повод ни в пользу BDD, ни против него. Но когда вы противопоставляете это другим подходам, таким как пользовательские истории или требования, тогда все подходы к разработке ПО страдают от языковой неоднозначности, поскольку все они так или иначе начинаются с формулировки естественного языка.
Технически проблема языковой неоднозначности была решена с помощью искусственных языков, таких как ложбан , но, опять же, ваш клиент и разработчики, скорее всего, не будут знать этот язык.
Вездесущий язык
BDD идет рука об руку с идеей вездесущего языка. Возможность задавать сценарии вместе со всеми заказчиками, тестировщиками и разработчиками просто дает BDD преимущество над другими подходами.
Рассмотрим традиционного инженера требований, записывающего все требования. Как только вы, как тестировщик или заказчик, получите этот 300-страничный документ, полный требований для проверки, у вас возникнет гораздо больше насущных проблем, чем в используемой там терминологии.
Пользовательские истории немного лучше в этом плане, поскольку они также включают в себя все заинтересованные стороны. С точки зрения вездесущего языка, я бы не сказал, что BDD или пользовательские истории лучше - хотя они значительно отличаются в следующем пункте.
способность быть свидетелем в суде
Основным аспектом BDD является то, что ваши спецификации на самом деле исполняются (через Cucumber или тому подобное). Ни требования, ни пользовательские истории не предлагают эту функцию. Лично для меня это главный пункт продажи BDD.
Сравните это с традиционными требованиями - мы веками говорили инженерам по требованиям, что их требования должны быть проверяемыми. Тем не менее, каждый проект сталкивается с ситуацией, когда где-то в будущем тестировщики понимают, что они понятия не имеют, как проверить определенное требование.
Пользовательские истории, если все сделано правильно, включают тестировщиков на ранней стадии их создания, чтобы убедиться в этом. К сожалению, это тот случай, когда теория сталкивается с реальным миром, где я видел множество историй, которых раньше не видел ни один тестер.
С другой стороны, BDD автоматически дает вам исполняемый сценарий тестирования. Нет никаких оправданий и способов обойти это (хорошо, если вы полностью не игнорируете слои автоматизации и просто записываете сценарии для причудливой поэзии).
В более общем смысле, Test First - это принцип, который был очень полезен на всех этапах разработки программного обеспечения, а BDD - его применение на самом внешнем уровне разработки (по сравнению, например, с TDD на уровне устройств).
Резюме
Таким образом, BDD не избавляет вас от проблем неясности естественного языка. Это, однако, поможет вам решить эту проблему с помощью двух важных моментов: сосредоточиться на вездесущем языке, чтобы уменьшить неоднозначности (это не устранит их полностью, но это очень поможет!) И заставив вас написать исполняемый файл технические характеристики. Последний момент помогает решить проблемы неоднозначности главным образом потому, что именно в этом случае двусмысленности начинают проявляться как проблемы в противном случае.