I would like to start using TestComplete with BDD approach, either with Cucumber or Lettuce.
In this article both I can go for Cucumber or Lettuce.... What is best to choose? What works best?
Any tips, feedback, best practices are welcome!
Thanks. Mathijs
My advice is make sure you have SOLID backing and support for it first.
I've seen BDD approaches (one using Fitnesse, one using SpecFlow) fall by the wayside within two different employers. Both were welcomed initially, had VERY good developers working on them, we're liked by analysts and testers also, and initially produced great results.
And neither lasted.
People got moved. Other things got priority. Management viewpoints changed. Long term maintenance of the fixtures became a chore. And they both got abandoned in the end.
Which is a shame, as both looked good at the start.
(I didn't work directly on either, but did work directly with people who did)
Colin_McCrae Thanks for sharing your experience
according to this BDD and GUI testings are two level of testing
how would you see TestComplete with BDD ? dose it replace need of two test code base or Just TC is driving BDD?
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 ....
