This month has been all about developing the Project Electron transfer application. The work is based on our defined specifications and the development decisions we made last month with our Marist College partners at the hackathon. We are really excited about testing transfers in the coming month.
In this post I am going to briefly discuss Gherkin, which in addition to being a delightful little cucumber, is a language that is used to define the requirements of software in order to document and test the software’s behavior as part of Behavior Driven Development (BDD). We have been using Gherkin to write Quality Assurance (QA) tests for the functions of our Project Electron transfer application. The language is human-readable, so it can enable communication between teams working in different domains across a project.
The Gherkin language is structured into statements of Features, Scenarios, and Steps using a syntax of text lines and indentations. As shown in the example below (from the Gherkin Documentation), a feature defines what is to be tested. A feature will likely have multiple scenarios, which are more specific situations that could occur as part of that feature. Steps are defined is Givens, Whens, and Thens. Given a precondition, When an action occurs Then a testable outcome results. And is used to add additional Givens, Whens, and Thens.
As part of the development of the transfer application, we will be testing features of the application. These will include features like bag validation of size and filename, virus checks, validation of bag metadata, user login, and account management. Below is an example of a Gherkin scenario we wrote for the virus check feature, which tests how the application will handle the identification of a virus found in a bag.
For me, being new to BDD concepts, Gherkin, and unit testing, I found writing these features/scenarios for our work to be useful beyond their functional purpose; the process helped me better understand the functional requirements of the application by forcing me to think through possible scenarios and outcomes. I did struggle initially with avoiding implementation details and focusing on the behaviour of the application in the Gherkin tests. For me, it was essential to step back and take some time to learn the basics of BDD, Test Driven Development (TDD), and unit testing as a conceptual foundation before jumping into writing Gherkin tests.
As we move forward with Project Electron and QA processes, these Gherkin tests will not only help us test the behavior of the transfer app, but also isolate and clarify its expected functions in a language that is accessible to all members of the project.