BDD is about the conversations - getting people together with a business mindset, a dev mindset and a tester mindset to discuss what needs to be built.
From that discussion you get a good idea of the business requirements - and hopefully some examples of how they should play out.
The person with the business mindset will have some of those examples that are important for them to be automated as business facing acceptance tests. The one's you write in gherkin.
The person with the testing mindset will have a bunch of ideas about how you can break this. Some of those will be important enough that they should become business facing tests, but often the group can decide that these would be better tested by unit tests.
You can't test for a particular outcome given an unknown set of input data.
If you have a known snapshot of data, you can set expectations for how you want your system to behave under those circumstances.
If you create a world where IMDB would rank highest for your indexing algorithm for the term "avatar", then you can expect that when you run a search it will be returned as the first result.
BDD is about the conversations - getting people together with a business mindset, a dev mindset and a tester mindset to discuss what needs to be built.
From that discussion you get a good idea of the business requirements - and hopefully some examples of how they should play out.
The person with the business mindset will have some of those examples that are important for them to be automated as business facing acceptance tests. The one's you write in gherkin.
The person with the testing mindset will have a bunch of ideas about how you can break this. Some of those will be important enough that they should become business facing tests, but often the group can decide that these would be better tested by unit tests.
We call this meeting the 3 amigos.