Second step of BDD - write "failing scenario step", does it mean the test for it?

Question

Knowing that BDD somehow avoids using the term "test", I am trying to understand the process as described in a book called The Journey to Enterprise Agility: Systems Thinking and Organizational Legacy.

They describe the BDD process like that:

1. Select a scenario from a feature
2. Write a failing scenario step
3. Write a failing test to support the behaviour detailed in the failing steps
4. Write the code to make the unit test pass
5. Refactor
6. If the step passes, move on to next step, otherwise discover more objects to support the behaviour detailed until step passes.

The "Given", "When", "Then" are considered the steps.
The sample scenario was "Given I am on a product detail page.."

Below the diagram, they explain: ...

The next action is to create a failing scenario step. In this instance, you would create code that confirms that the product page can be displayed.

I do not get it. What is the failing scenario step, if not a test (and it does not seem to be the test as those are mentioned in step 4)? If it is not the test (but any other code), am I not breaking the TDD rule (test first)?

The link to the book and original text: https://books.google.de/books?id=p30gFQycCHEC&pg=PA493&dq=BDD+process+refact&hl=cs&sa=X&ved=0ahUKEwi5pcypr57bAhXD_aQKHexgB2AQ6AEIXTAG#v=onepage&q=BDD%20process%20refact&f=false

Answer 1

A scenario is just a piece of human-readable text. To write a failing scenario step here means to translate the pieces of the scenario into executable test code, so that you can automatically check whether the scenario has been implemented.

This is particularly clear if you are using Cucumber to write the scenario. The Cucumber test runner will parse the scenario but mark each step as not implemented. You will therefore have to first write the necessary code to parse and execute that step, i.e. turn the scenario into a test. Some or all of these steps might fail initially. In a given/when/then style scenario, at least the “then” step should fail. While writing the step, you might also rephrase the scenario to make it clearer and easier to parse.

You now have an automatically testable scenario with failing steps. Next, you would pick one step and move into the TDD loop where you write unit tests and write code until that step starts to pass. Once that's done you move back into the BDD loop and continue with the next failing or unimplemented step, or with the next scenario.

Yes, scenarios are certainly a kind of test when treated like this. But being automatically testable is only a secondary concern, and scenarios are primarily about clear communication between customers or domain experts and developers. BDD-style tests/scenarios are typically high-level, user-oriented, end-to-end, and focused on business rules. In contrast, unit tests incl. TDD-style tests are more granular, cover smaller components, and are more concerned with the interfaces of the code under test.