BDD Framework

I'll do my best to cover BDD in 5 consumable steps:

1) I would recommend a good article on BDD [here] and video series w/TestComplete [here] - to summarize, BDD methodology is just ensuring business analysts, developers, and QA are all involved in the requirements gathering and refining of the acceptance criteria of development items - using the Gherkin format as a guide to create executable specifications or definitions of the steps that need to be performed to validate the functionality.    

2) Cucumber is a tool that supports BDD by using the Gherkin language - it's just another testing tool, like Selenium or TestComplete (more on these later), that is used specifically for testing software.   

3) Gherkin is written in natural language syntax AKA plain English (or your native language) and is essentially a language parser that uses keywords like Given/When/Then to help format and identify the actions of the steps within.  

4) Let's do an example... let's apply this methodology to our pretend business workflow. The business owners and stakeholders come to the development team and say they want to add some new keyboard shortcut features. Traditionally, the requirements and acceptance criteria for this feature would be something like "when a user presses "CTRL" + "j" they are taken to the Downloads page". Then DEV, QA, and BA's create their own interpretation of this vague criteria.  

That may good enough, but by guiding the project team using the Gherkin Given/When/Then format you tend to uncover various other requirements that need to be considered like, "A Chrome browser needs to be open" and "the page needs to be maximized" or "the user needs to start on the homepage" or "redirected to the chrome://downloads/ url".  

Now you have more precisely groomed your work item using the Gherkin format and the test cases have essentially already been written within this acceptance criteria - so developers can use this as a guide for their logic and automation engineers can copy-pasta the Gherkin steps into a Feature file to start scripting out the step definitions.  

Below you can see how this Gherkin format breaks the acceptance criteria down to a single test case, which is referred to as 'Scenario' or 'Example' in Gherkin. This is a single test to verify a keyboard shortcut in Chrome redirects to the appropriate webpage:  

# SCENARIO: test case 
Scenario: Verify Chrome Downloads Keyboard Shortcut
# GIVEN/WHEN/THEN: precondition/action/validate
  Given The Browser is running and a webpage has been maximized
  And The user has navigated to "https://www.google.com/"
  When The user enters "Ctrl" and "j" on the keyboard
  Then The user should be redirected to "chrome://downloads/"  

From these steps you can create 'step definitions' (in a separate script file - or script unit in TC), which are references to the words that are used with the Gherkin keywords [reference].

Let's start with the 'pre-condition' or 'Given' something needs to be done before performing an action:  

Given("The Browser is running and a webpage has been maximized", function (){
  // write in your preferred language (JavaScript, Python, VBScript, C#, C++, etc) 
  Browsers.Item(btChrome).Run("https://smartbear.com/", 2500); 
  Sys.Browser().BrowserWindow(0).Maximize();
});  

Now we have a function that gets called whenever the phrase "The Browser is running and a webpage has been maximized" is used in a 'Given' step. Simply by using the Gherkin format and keywords, I have now defined a reusable step that can be used to test multiple test cases within a feature - which is the value of BDD, simplifying and breaking down steps in a more logical, programmable, and consumable way.   

Let's move to the step definition of the second 'pre-condition', which passes an argument as a parameter to the 'Given' function:  

Given("The user has navigated to {arg}", function (param1){ 
  Sys.Browser("*").Page("*").ToUrl(param1);
});  

Cucumber is searching again for a 'Given' phrase with "The user has navigated to" and passing in the variable argument from the Gherkin script - in this case "https://www.google.com/". Now this step has become more dynamic by accepting different inputs to pass in during the test.  

Assuming you follow the same methodology all the way through the When/Then steps, you can verify your test case in your own unique way. To take this example a step further we can use 'Scenario Outline', instead of the 'Scenario' keyword, to run the same Scenario multiple times using different combinations of values fed from an Example table (data-driven test):  

Scenario Outline: Verify Browser keyboard shortcuts (data-driven test)
  Given The Browser is running and a webpage has been maximized
  When The user has pressed <input1> and <input2> on the keyboard
  And The user enters the final <input3>
  Then The user should be redirected to <redirect>

Examples: 
  | input1 | input2 | input3 | redirect | 
  | "Ctrl" | "Shift" | "o" | "chrome://bookmarks/" | 
  | "Ctrl" | "h" | "" | "chrome://history/" | 
  | "Ctrl" | "u" | "" | "view-source:https://www.google.com/" | 
  | "Ctrl" | "Shift" | "Delete" | "chrome://settings/clearBrowserData" |  

I have now created the same test using 4 different scenarios and I haven't had to add much in terms of backend code (the step definitions) - just another example of how BDD can be used to make tests more readable and more versatile in its implementation.  

** NOTE: BDD is not perfect for every scenario and more complex test cases would certainly not fit within this mold - HOWEVER the beauty in BDD is that it's not required to create automation or to even write test cases in this format, it is best suited to help define the acceptance criteria and provide examples for your team's work items.   

5) With all of this being said, it may seem like an impossibly daunting task to undertake and there are a million place to look - the key is just to start looking...and have fun breaking things. Try [Smartbear Academy] too.