Behavior Driven Development. Why?

           As we embarked on pivotal journey with all enthusiasm and excitement, there was one hitch that was bothering us. Balanced team structure, recommended by pivotal emphasized on developers being responsible for testing and CICD.

Setting up CICD was a cake walk for us, with the CICD tools available in market and the latest advancements in this area. We used Gitlab and set up CICD pipeline without any significant obstacles. This left us with the next challenge to solve, developers to own complete testing.

For most of us developers, writing tests isn't as interesting as implementing features of the product, now one more dimension got added to it. Nevertheless, we had made up our mind, there was no turning back. We geared up to implement and own unit, functional and integration testing.

 We soon started facing difficulty to implement tests before developing features. Though writing tests for public methods appeared straight forward, it posed challenges as developing these public methods would involve structuring code into different layers and we would go back to test to mock these dependencies. During this process, even though we started implementing tests first, we would eventually end up developing/thinking of dependencies while writing tests for the public methods. Hence the purpose of writing tests upfront to ensure tests are not influenced by technical implementation got lost. We had to find a way to tackle this challenge. After lot of research and analysis, we decided to adapt Behavior Driven Development - BDD.

Behavior Driven Development

BDD works on two major Concepts

Tests for any product must be specified in terms of Desired behavior of the product.

Product Behavior must be specified in terms of user stories. It should in some way follow the below template

Story Template

Sample Story

Test Template

Sample Test

Benefits

• Easier adoption to Test First Approach -Test creation begins with naming the test case with As a [role] I want [feature] so that [benefit], corresponding to the acceptance. Tests are written with focus on behavior, rather than thinking about how the code in the subsequent layer be, as mocking is done only for dependencies outside the assembly. 
• Less number of Tests - The number of tests that needs to be implemented are almost same as the number of acceptance criteria. Tests must be written to cover every behavior of the product. There is no need to write tests for the intermediate layers within assembly.
• High Code Coverage - More than 95% of code coverage can be easily achieved. Redundant code gets easily identified.
• Less effort - Eliminating the mocking of intermediate layers in the assembly leads to less test setup, initialization and fewer tests.
• Fewer Regression Defects - Defects introduced due to code refactoring, design change are caught easily, as any test executes code in all layers of the assembly, covering the interaction between layers.
• Documentation - Every acceptance is documented as a test which resides along with the code. As a [role] I want [feature] so that [benefit], then naming format enhances readability. Thus, also serves as documentation for product feature which could help during new resource on-boarding.

Finally, what prompted me to write this article?

        All through my career, whenever I ran first round of test coverage, the result would be around 70%. Later, identifying the code uncovered and bringing up the coverage to 85% benchmark used to be a TASK. After adopting BDD, first time when I ran the coverage the result was 95%. After excluding few system-generated entities; Bingo, it raises to 98.3% to my Delight. Upon checking with my teammates, figured out almost everyone had similar experience.

            Less effort high value :)