My interpretation was he wants to develop tests on TC using a BDD approach.
In other words, provide a pseudo-language which allows non-technical testers to write tests which then drive the TC fixtures which actually run the tests. So the BDD will be driving TC development, not development the AUT.
Right?
In which case, I'll add a little more ....
My framework *sort of* allows for this type of approach. I provide a keyword and data driven framework. Anyone can fill in a spreadsheet and create a test. But mine is more granular and directly linked to the functions and methods of the controls in the application/site first, and then into specific functionality of an application second (where required).
So it's a two layer approach. The central core are the "handlers" which deal with certain types of control. These are re-usable and portable from project to project. The secondary layer (which, ideally, should always be MUCH smaller) is more tied to functionality or behaviour of the specific application/site. No matter how much I've tried to neutralise and abstract the test layer over the years, I've always ended up with a few application specific functions. Usually as it saves a LOT of work trying to make something generic that you'll probably never use again. As long as it's kept to a minimum, I'm OK with that.
The BDD natural language approach strikes me as much more difficult to implement as exactly what each line of pseudo-test-code can be quite widely open to interpretation. Especially as it's now two layers away from what it will actually be testing. And if both are being built at the same time (the application AND the test fixtures to test it in TC), but separately, I can see all sorts of potential problems ....
