In the world of SAFe, a Dev team should have a unified foundation of work to ensure ease of application for all code that is written. The smaller a story is, the faster it gets put into development, and production, and we catch bugs sooner and more efficiently. However, there are tools and methodologies we can use, to help us mitigate these errors more than just making stories smaller. Test-Driven Development (TDD) is one of a few methodologies that go into this unified foundation of work.
TDD can be summarized as: A developer writes a Test for a portion of code that they have yet to write, but that Test is written to purposely fail. Then the developer writes JUST enough code to ensure the Test passes. Rinse and repeat. This introduces a small bit of redundancy into the developers' code bank, but when it comes to code fixing and bug finding, a bit of redundancy to prevent those isn't a bad thing. TDD is a good tool for any developer to have in their tool-belt.
A major drawback for Test-Driven Development, however, is that it is code heavy and specific in the team's script language or Domain Specific Language (DSL). That's amazing for the team, where TDD is based, but less so for any Business Owner, or Stakeholder who does not read that DSL. They could probably parse out a general idea of what the developer was trying to accomplish, but not everyone has that ability or skillset. This is where Behavior-Driven Development (BDD) comes in.
Test-Driven Development lives at the team level, much like Stories. Any given test is written by a Dev Team member, and not a Business Owner or Stakeholder, again like Stories. Above the team are where the PO/PMs or the B.O.s live. This is where BDD gets put in front of the Dev Team, for the team to look at. This is also where the team decides how to implement the vision that the leadership has put forward, much like Features. The Team doesn't write Features, they write Stories. The same applies for BDD and TDD respectively.
Well what IS Behavior-Driven Development? BDD can be summed up as a Scenario. A Business Owner will put themselves in the shoes of a Role, and visualize what that Role would want, based on certain real-world inputs. They will then convey that vision, using the outline structure (formula) of: Title, and Acceptance Criteria. When put into practice it should look like:
A descriptive title
A full example will look like:
Returns and exchanges go to inventory.
Scenario 1: Items returned for refund should be added to inventory.
Scenario 2: Exchanged items should be returned to inventory.
In the above scenario, the Business Owners have placed themselves in the shoes of an Inventory Manager. This helps give the Dev Team context to form a As A, I Want, So That, that assists the Business Owner achieve their vision.
In a perfect environment BDD and TDD work in tandem to achieve one unified goal. To give clarification to the development team, and to ensure that code is written properly and functionally. They are not mutually exclusive; however, teams are not required to have both. Most agile teams start adopting Test-Driven Development first, before moving on to adopt Behavior-Driven Development.