I'll start with where we are, then I'll present the problem we are trying to solve. I'll follow that with some of the things we've looked into, and end with my ultimate question.
Where we are:
1. We have a Selenium-based framework in place to manage the ins and outs of a given web application using .Net
2. On top of that, we have a set of page objects that govern the ins and outs of our various applications
3. We have an up to date set of regression tests written for each application
We would like to take the items used in 1 and 2 above and use them to support some form of keyword or BDD testing
At the outset, Specflow seems ideal, but it requires test features to be available at compile time. This would also require our QA team to use Visual Studio, which is not ideal.
NBehave is also not necessarily the right choice, as it seems lacking in community support.
Using more traditional keyword styles is also less than ideal. I am uncomfortable with the maintenance aspect of having locators and object names in an external data source. Also, the language has to be exact, and I am unaware of a tool that simulates intellisense when creating test cases, to force use of common artifacts.
We have also considered using Excel spreadsheets with the language held in secondary sheets, building test cases out of the common language, then importing those into Microsoft Test Manager, to be finally interpreted at runtime by the tests themselves. Convoluted, but ultimately interesting.
And so, we get to my question. Does anyone have experience with, or advice on, a BDD/keyword approach that uses external input files, built with some kind of intellisense to enforce common language?
I usually just prefer to use long method names to simulate BDD, and use a code editors tools for easy refactoring. I think it has the same effect without reducing the flexibility of your test framework. And in my experience, most Product managers don't like writing Gherkin anyways. As useful as it is for Product to be very inolved in the test definitions, most companies I've worked for have their product managers spread too thin to really maintain test specs to make any BDD framework worth while.
I'd probably just focus on writing clean code and making test easier to debug, and avoid the whole BDD overhead. If you need BDD, you can just use creative method naming to have the same end result.
I was on a project where each keyword had a different amount of parameters for different things. I used VBA for Excel to examine the keyword in column 1. The user pressed F3 and then rows were created for the comment of what the keyword does. The next row was for parameter headings. Then the data entry was intelligent. It would fill in dropdown with a default. it filled in default information.
It worked by using other Excel sheets as a look up. It took time to build and maintain. I could not get a copy of the SW. The idea could be re-used.
When in Florida, Don't Tampa with the code. I made this up.