Continuing on the previous post on the Tesla Auto Pilot crash mode malfunction, here is a working code example of the feature.
The advantage of BDD is that you can not only keep the business engaged in the development process but also ensure that there are no disputes nor any cost of change as every business requirement gets neatly described as features from which all the possible scenarios based on business rules can be elaborated into crystal clear test cases.
The other advantage, of course, is that Test Driven Development becomes easy to implement as the BDD phase effectively outlines just those test cases for code to be written against for the feature to be realized.
Here is the example scenario of the auto-pilot mode beeping if the car is in auto-pilot mode.
So, effectively, there are two scenarios for the feature test to pass -
1. The car should be on auto-pilot mode.
2. The beep should be set on only if the auto-pilot mode is on and there is an object ahead.
Remember that BDD is about testing scenarios and so we don't have asserts but expects.
npm Packages used: jest, jest-cucumber, typescript, babel
Platform: nodejs
Dev tool: VS Code
Language: English :), typescript
jest-cucumber, by default, checks all tests defined under a _tests_ folder and if one does not exist then it follows the path given in the config file or in the testMatch in the package.json file.
The feature is clearly described in a .feature file as below. Remember that the gherkin syntax of given, when, then should match the scenario described in this .feature file.
The gherkin steps are defined in the .steps. file.
The actual code to test the expectation is the source code as below:
Run the test with jest.
and running the test would cause the test runner to display errors because the scenario text has changed and does not match the scenario being tested for in the .steps file.
Similarly, if the source code running the test is changed and the distance is not set, then, too, the test will fail because expectations are not met!
From the above, you can easily perceive that the advantages of using jest-cucumber for BDD are obvious and numerous.
The advantage of BDD is that you can not only keep the business engaged in the development process but also ensure that there are no disputes nor any cost of change as every business requirement gets neatly described as features from which all the possible scenarios based on business rules can be elaborated into crystal clear test cases.
The other advantage, of course, is that Test Driven Development becomes easy to implement as the BDD phase effectively outlines just those test cases for code to be written against for the feature to be realized.
Here is the example scenario of the auto-pilot mode beeping if the car is in auto-pilot mode.
So, effectively, there are two scenarios for the feature test to pass -
1. The car should be on auto-pilot mode.
2. The beep should be set on only if the auto-pilot mode is on and there is an object ahead.
Remember that BDD is about testing scenarios and so we don't have asserts but expects.
npm Packages used: jest, jest-cucumber, typescript, babel
Platform: nodejs
Dev tool: VS Code
Language: English :), typescript
jest-cucumber, by default, checks all tests defined under a _tests_ folder and if one does not exist then it follows the path given in the config file or in the testMatch in the package.json file.
The feature is clearly described in a .feature file as below. Remember that the gherkin syntax of given, when, then should match the scenario described in this .feature file.
The gherkin steps are defined in the .steps. file.
The actual code to test the expectation is the source code as below:
Run the test with jest.
Now, change the scenario description.
and running the test would cause the test runner to display errors because the scenario text has changed and does not match the scenario being tested for in the .steps file.
Similarly, if the source code running the test is changed and the distance is not set, then, too, the test will fail because expectations are not met!
The code change is the commented call to the method that sets the object ahead's distance (hypothetical) and so the test will fail when it tries to match the distance between the car and the object ahead.
Similarly, if the auto-pilot mode is not set the test will fail as that is the base scenario test!
- Business can easily stay on track with development efforts.
- Wastage in effort and time as well as cost is reduced due to the traceability of requirements to code and vice-versa.
- Code waste is reduced. Only that much code is written in the TDD phase as defined by the BDD phase.
- Audits become simple because of the end-to-end testing available with one click.
With scaled agile frameworks like Safe, which require BDD and TDD to be well implemented, jest-cucumber and jest are incredible tools to infuse maximum agility into the software development process.
Of course, this is not to say that other tools like SpecFlow that are used for other frameworks like .Net or Java are not good, they all serve the same purpose - of defining features, deriving scenarios, writing test cases either in gherkin form or otherwise to automate the testing of your system.
Binding the test results from the above phases along with Selenium or Acceptance/Functional tests with test coverage completes the automated requirements for DevOps.
Happy BDD-ing! :)
Of course, this is not to say that other tools like SpecFlow that are used for other frameworks like .Net or Java are not good, they all serve the same purpose - of defining features, deriving scenarios, writing test cases either in gherkin form or otherwise to automate the testing of your system.
Binding the test results from the above phases along with Selenium or Acceptance/Functional tests with test coverage completes the automated requirements for DevOps.
Happy BDD-ing! :)
