When it comes to TDD and BDD, the acronym MECE comes to mind: Mutually Exclusive, Collectively Exhaustive.
TDD (Test Driven Development): Stories — just like Objects in the Object Oriented world — are independent… self-contained and meaningful on their own — all stories have a sense of exclusiveness. All stories are mutually exclusive and each can be tested as a unit. 
In TDD, a rich set of Unit Test scripts are written and ran… failures are observed …write code to pass the tests … run all tests again and observe pass / fail … then refactor as necessary. This rich set of unit tests ensures that refactoring efforts do not introduce new errors… allowing developers to continuously improve their designs. Unit Tests (code tests) should be automated… and part of the automated ‘daily build’.
As to BDD (Behavior Driven Development), a certain context is involved and usually involves one story or more — a collective of stories (feature, capability) — to pass a collectively exhaustive set of tests within a context, scenario or domain. It comes in the format of Given-When-Then: i.e. Given a certain context, domain or scenario, When a certain action is invoked or carried out, Then, a particular set of observable consequences should happen. Example: Given my bank account is in negative balance, When I attempt to make a withdrawal, Then I should get an Error. Automate this when possible, although manual is fine.
ATDD (Acceptance Test Driven Development) answers the question “Are we building the system right? Does it do what it is required to do?”. The answer lies in the Acceptance Tests. ATDD focuses on capturing requirements in acceptance tests vis-a-vis acceptance criteria and uses these captured requirements from acceptance tests to drive the development. ATDD is a collaborative practice between users, testers, and developers. This supports what SAFe 4.6 is espousing: Test-first 
and test automation for fast feedback.
All in one glance: to make things clearer, there is a diagram that shows various test embodiments in four quadrants. 
TDD belongs on the first quadrant (Q1)… whereas BDD belongs on the second quadrant (Q2). SAFe’s Continuous Integration (CI) provides more information on quadrant three. NFRs, CI, SAFe’s Release on Demand provide more information on quadrant four. ATDD belongs primarily on Q2 but can be on all four quadrants where acceptance criteria and acceptance tests exist.
Indeed, SAFe 4.6 is quality centric by — but not limited to — promoting the notion of: 1) achieve quality by test-driven development, 2) test-first and test automation for fast feedback.
