TDD taken to logical conclusion - write acceptance tests first

I'm reading an interesting book called Growing Object-Oriented Software Systems by Steve Freeman and Nat Price (based on @mfeathers recommendation).

For the most part the first two chapters are nothing new for me (I'm expecting that will change in subsequent chapters), but there was one thing that made me stop and step back.  To me TDD has been about unit tests, but they strongly recommend something that I had never though of before but which made a lot of sense.  Not only do you write tests first at the unit level, you also write your end-to-end acceptance test first.

This gave me pause.  I am so used to QA reactively writing acceptance tests either after or in parallel with feature development.  But the more I thought of it, the more it made sense.  It defines a contract in black-and-white, and it also helps you focus on building just as much as you need and no more.

Of course the acceptance tests will break, and then you work towards making it pass by writing unit tests that break and making those unit tests work.  This really makes sense, and I'm going to try this with my next project.  I talked with our QA engineer, and he loves the idea and wants to give it a go.

If it works, I'll talk to the rest of the team about it.  This is the kind of thing that turns standard development process on its head and has to be introduced very gently... :)