Despite being very stakeholders friendly, ATDD aimed to provide a "stop" line when a feature has just been done. This avoids wasting time to add non-focused (and sometimes useless) code.
That's why some teams start by establishing a walking skeleton of the application, and directly specifying with an acceptance test the first required feature.
Let's suppose this first acceptance test (not representing a relevant first acceptance test, just being an example):
Given Michael has just been created in the application, his status should be left to non-activated.
I want to write my acceptances tests focusing on business logic directly (use-cases), not dealing with GUI for business rules.
Thus my question would be...how to write it? since I don't even already know what is a "User", what is a status etc... Indeed, shouldn't it be the role of TDD to emerge the design and therefore these components?
But if I firstly practice TDD in order to emerge them, the benefit of ATDD (as a stop line) would disappear.
I imagine that it would be more consistent to write some acceptance tests (before entering TDD cycle) when the project has well progressed, since all main components would already be designed.
To sum up, should I always write my acceptances test BEFORE my TDD cycle?