start each feature with an acceptance test

Domain Language only

write the acceptance test using only terminology from the application’s domain,

not from the underlying technologies (such as databases or web servers)

benefits:

• prevent assumptions about implementation

• clarity

• focus on limited set of features

• user's point of view

(src: Book: Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce)

In Book: Agile Technical Practices Distilled - Pedro, Marco, Alessandro they define test boundaries of acceptance test without external dependencies. (Model: Test Boundaries)

Outside-In TDD is also commonly know as “London school of TDD,” acceptance test driven development (ATDD) or mockist TDD.

sketch a collaborator and write the assertion around that collaboration

Restrain from mocking every abstraction layer in your module (model, bounded context).

Test it as black box through the public interface while being declarative and assertive about your interaction with other modules.

(src: Book: Agile Technical Practices Distilled - Pedro, Marco, Alessandro)