TestComplete BDD
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
TestComplete BDD
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
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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?
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ....
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
thanks for sharing your thoughts...
I thought only me facing ........... "No matter how much I've tried ......., I've always ended up with a few application specific functions. "
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Colin_McCrae, @NisHera thanks for the comments.
And thank you for sharing your thoughts Colin.
I like the BDD principles and was investigating it's potential application combined with TestComplete.
Read this, this, this and this article on it.
Personally I have come to the conclusion that BDD has definitely potential but the frameworks currently investigated (Lettuce, Cucumber) require way to much fragile configuration (settings project folders name, test names, etc, etc) to be able to use this effectively in Contiuous Delivery / Continuous Integration approaches. In practise you end up maintaining the configuration files, editing connection / integration scripts to keep alive the integration between Cucumber/Lettuce and TestComplete.
Therefore, I would go for a BDD framework within TestComplete (or another product from SmartBear) which can guaranty integrity of BDD features/specifications/test-steps on the one hand, and the actual tests (whether these are scripts or Keyword tests, on the other hand). See this feature request.
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi everyone!
I'm happy to announce that we've implemented BDD support in TestComplete v14. There are two ways you can get started -
1. Within TestComplete itself: https://support.smartbear.com/testcomplete/docs/bdd/index.html
2. With our continous testing platform: https://support.smartbear.com/testcomplete/docs/working-with/integration/hiptest/index.html
Hope this helps you accelerate your BDD efforts.
Prashant
