Pyramid Practice of TDD and BDD
At Pyramid, we have quality standards and take utmost care to do thorough testing of code by the development team. This approach includes doing manual testing, coded unit testing and code coverage. Our approach to code testing is usually a mix of both Unit Testing and Behavior Testing. In Unit Testing we test the code statements that we write and with Behavior Testing we test the scenarios of the feature that we implement. We can write a Test Case before writing the code or after writing the code and that depends on what the stakeholders have agreed upon. Writing unit tests first and implementing the code to pass the tests is known as TDD (Test Driven Development). Similarly writing the acceptance test cases first followed by implementation is known as ATDD (Acceptance Test Driven Development). Driving the implementation by writing Behavior Test is known as BDD (Behavior Driven Development).
Writing TDD or BDD is a part of our delivery best practices. We believe that “code not tested is not done” and therefore we also ensure we test the code we write. Agile developments are incomplete without unit test and code coverage.
“Code not tested is not done”
Along with the coding guidelines we publish unit testing guidelines for developers. Recurring Tech Talks and Trainings are organized for such best practices. During our regular audit cycle , we review the “code coverage” report and quality of the unit test cases written based on our published unit test guidelines. Whenever there is a smell or coverage is below the benchmark defined in project plan, it is escalated to the Quality Control Board so that necessary corrective action is taken in time. Full cooperation from all stakeholders is required to make it success otherwise it is moved towards lower priority.
Whether we write unit test cases or we write behavior test cases, code coverage is always generated and reviewed. It is up to the stakeholders to choose which approach to be followed. TDD or BDD? I have experienced that if it is a TDD then business stakeholders have little or no interest in it because it doesn’t give any business value. If it is BDD then business sees some values as they can see the acceptance test cases are automated but it doesn’t test the code written by the developer. Some stakeholders choose not to have unit test cases but that is a different case and they pay the price post-production.
To provide value to both business and developer, we follow the fusion of TDD and BDD. One major guideline for implementing the BDD flavor in unit testing is to name the test methods with scenarios. Example is below:
A unit test name: “TestCalculateHouseRentAllowance”
A recommended unit test name that express the behavior. It gives a BDD flavour: “TestCalculateHouseRentAllowance_BasicSalary3HundredThousandThenHRAshouldBe50K”
Inside the test method, we write test cases to cover the codes and branches. Also we ensure the acceptance test criteria are passed. If stakeholders are happy to bring in BDD frameworks like Gherkin and Cucumber SpecFlow, we easily integrate it .NET and nUnit or MsTest. Practice remains almost same. We do the same for Java. Our QA Test Automation sometimes follows the option of integrating Gherkin BDD approach with Selenium WebDriver to automate frontend testing.
Below is a BDD expression written in Gherkin language:
Scenario: Calculate House Rent Allowance for Salary Greater or Equal One Million
Given Basic Salary is “300,000"
When Calculate HRA
Then The calculated HRA should be “50,000”
Our expertized TDD frameworks are nUnit, jUnit, MsTest, Visual Studio Test. Our expertized BDD frameworks are Gherkin, Cucumber Specflow, Jasmine, Karma and Protractor. We undergo unit test coding for almost all .NET based technologies, Java based applications, Ruby, PHP, Angular, Vue.js, React.js, etc. We integrate these frameworks and unit test execution inside CI (continuous integration) pipeline. Technologies that we have covered with BDD are C#, WCF Services, Web API, Angular, Vue.js, React.js, JavaScript, Java.
We have come across a long journey of TDD and BDD, challenges in implementation, complexities of adopting it in existing applications. When automation are at all not in favor, we do manual unit test execution.
Author Bio:
Chingangbam Irabanta is Chief Architect in Pyramid IT Consulting, NOIDA.
He contributes blogs and articles to the community. He holds a master’s degree in computer application and have over 16 years of industry experience.
