BDD – Behavior Driven Development

Posted on December 2, 2016 By

Continuous Integration using Behavior Driven Development Tests for Clients recently have entailed the use of Specflow, NUnit (Like JUnit), WebDriver, Selenium, C#, HTML and similar technologies within a technology “stack”. BDD as it is called is but one key PART of a unified continuous test, build and deploy strategy employed in the software development life cycle.

BDD uses a simple “human language friendly” means of gathering the USER and OWNER expectations of what an application should do when certain actions take place within a running application, for example:

• “when I do “this”, and “this” happens

• then when “that” happens and has been “verified”,

• I will then do “this” other thing and “something else” happens.

• ETC.

The BDD process converts common sense action statements into method stubs which eventually are then developed to activate the running instance of an application/page object of the application via a POM, which is an acronym for a Page Object Model class. Each POM applies to objects within a specific screen or view of a running application..

There are also Actions that can be taken or completed via the application which are defined and accessed using the LFM (Logical Functional Model), which is the series of “methods” or “functions” that each view of the application offers to the user for operation.

Clicking a button, entering text or selecting values from a list, are all “actions” that perform business functions based on the underlying required business/application logic.

Typically what follows are some verification steps that the program uses to test and confirm that the desired actions have taken place, just for example:

• a new page is loaded

• a new value is committed to a database and confirmed

• a text value is changed in the application

• a visual element of the page is altered, rotated, updated or similar action

This kind of test automatically runs in a comprehensive application specific manner, whenever the application is updated, or expanded via a test server like Jenkins or Team City. These are instances of Build/Deployment test servers, which take the application under development, every time it is updated… and build it for the end user configuration. Then it runs the BDD tests to see if all the desired and expected outcomes and data flows, are as required.

They do this by performing a complete series of pass/fail tests, notifying pertinent team members whenever failures have occurred. They function much like a human user would, as application actions and values are tested, and expected outcomes are verified.

Whenever new behaviors are added or amended for the application, new BDD tests are continuously rebuilt and incorporated… capturing errors and unexpected regressions that may break the continuously deployed project at various integration points in the development process… sometimes tests are run very frequently because of rapid deployment teams, pushing successful changes to the build servers. Tests can be run every few hours or minutes… for that matter whenever check-in occures of newly revised or created code occurs.

BDD does NOT replace TDD (Test Driven Development ) performed by developers in the application building process. It serves to test the already unit tested application as it is or will be deployed. It is a best known practice to guarantee against regression and unexpected work flow conflicts between already deployed components of an application.

This will most likely be an application already built, tested and deployed but subsequently fails under unified deployment or changes to the grid of likely external environment scenarios.

A successful BDD plan, vigorously implemented, often acts as the last hurdle to jump, just prior to deployment of an application, assuring success within Continuous Integration contexts, where software is continuously and incrementally updated as the software is being developed.

Now that we have taken a high view of Behavior Driven Development, I intend to offer a basic presentation of some basics regarding a deployment process for a typical Jenkins Server on a not-so-typical free Amazon Web Service (EC2) that hosts a “MS Server 2012r” instance.

Programming     , , ,