1. Introduction
The Internet of Things (IoT) development community has been embracing new software development methodologies to make IoT system development faster, better, and cheaper [1,2]. With success stories of the adoption of agile methodologies in IoT-related areas such as embedded systems and hardware [3,4,5], the IoT development community can be expected to continue to look into new methodologies, especially the ones with proven results in the broader software development community.
In this context, this paper explores applying behavior-driven development (BDD) [6] for IoT systems development. As a relatively new agile software development method evolved from test-driven development (TDD) [7], BDD broadens collaboration by moving from developer-centric tests to whole-team executable specifications. BDD has gained a lot of traction in the software development community. According to a recent vendor survey, 37%, 44%, and a projected 50% of software development teams were adopting BDD in 2017, 2018, and the 3–5 years beyond, respectively [8]. With an ample amount of the literature (e.g., [9,10,11,12]) and many supporting tools available (e.g., [13]), BDD makes a good candidate methodology for IoT system development. Indeed, we are beginning to see positive results in applying BDD for developing real-time embedded systems [14], automotive systems [15,16], and avionic systems [17]. In our own experience, we have also benefited from BDD in the development of a smart cone system for protecting road maintenance crews working on highways [18].
Key to the success of BDD is the patterns that encourage the development team to specify collaboratively and illustrate with examples [9,10,11,12], thereby minimizing the gaps of misunderstanding between members of the IoT development team including domain experts, analysts, hardware and software developers, and testers. The captured specifications are recorded in textual descriptions written in a simple natural language template; an example is the Given-When-Then template of the Gherkin language [19]. Since well-written Gherkin specifications are readable and understandable by all team members, the specifications can be continuously refined throughout the life cycle of an IoT system for feature changes, extensions, and bug fixes. Further, through tool support, the Gherkin specifications of an IoT system are executable specifications that serve as acceptance tests to drive the subsequent coding and testing activities [9]. When frequently executed and maintained, the specifications turn into living documentation to replace the traditional requirements and specifications documentation that is prone to be out of sync with the current system behaviors [9,12].
Despite the merits of BDD described above, in developing the smart cone system which encompasses both sequential and concurrent behaviors [18], we found that the Gherkin language does not yet support the specification of concurrent behaviors. This inadequacy created some difficulties in writing specifications with Gherkin for our interdisciplinary team consisting of traffic safety specialists, hardware engineers, embedded system developers, and software developers. In particular, the traffic safety specialists were unable to use Gherkin to precisely specify the concurrent behaviors of the smart cone system and had to depend on the developers to interpret the intended concurrent behaviors at the implementation level. We will further show that the concurrency inadequacy of Gherkin can lead to specification errors with two IoT examples in Section 3.
To fix this inadequacy, we propose an enhancement to Gherkin to support the specification of concurrent behaviors. We follow the parsimony principle [20] by not adding new keywords to Gherkin. Instead, we introduce the concept of sequential groups of concurrent steps by limiting the use of Gherkin keywords
To fully support the concurrency enhancement, we develop an embedded Gherkin tool support named
The rest of this paper is organized as follows. Section 2 covers the background of BDD and tool supports. Section 3 presents the two examples demonstrating the specification errors that could result from using the current Gherkin language and tool support for specifying concurrent behaviors of IoT systems. Section 4 presents the proposed concurrency enhancement to the Gherkin language and the supporting tool
2. Background
Since BDD derives from TDD, we begin by describing TDD. TDD is a widely adopted software development practice that advocates writing automated tests before writing production code [7,22]. Incrementally and iteratively, a test is added that specifies and verifies the functionality of a specific aspect of a small individual component. Then, just enough production code is written to pass the added test as well as all tests that were previously passing. The code is refactored for a higher quality before ending an iteration. TDD has been applied at all levels from acceptance testing to unit testing [23,24]. TDD has demonstrated successes among early adopters in IoT development (e.g., [4]).
As a derivative of TDD, BDD further aims to bridge the communication gap between domain experts, business analysts, developers, and testers by using a natural language in a simple but special format to specify software behaviors through concrete examples [6,25,26]. While different formats are available [13], this paper focuses on Gherkin [19], a popular language where specifications are written in plain text and supported by many tools.
2.1. Syntax and Semantics of Gherkin
The class diagram in Figure 1 shows the syntactic structure of keywords of Gherkin. At the top level is the keyword feature, which represents a unit of functionality that the software under development will have upon completion [27], such as transferring money between two accounts in a banking application, booking a room in a hotel application, and so on. A feature contains a number of scenarios, where a scenario is a concrete example that describes how the feature plays out under the specific circumstance. For example, the behaviors of transferring money will be different, respectively, depending on the source account having a sufficient or an insufficient balance before a transfer.
A scenario contains several steps which are interpreted sequentially in the order of appearance. A step begins with one of the keywords Given, When, or Then:
A Given step gives the precondition or the initial context of the scenario;
A When step gives the event or action that sets the scenario in motion;
A Then step gives the post-condition reflecting the effect of the event or action.
If a scenario contains several successive steps all beginning with the same keyword, each of the subsequent keywords can be replaced by an And or a But for better readability without changing its meaning; see Section 3 for an example. A feature and its constituent scenarios are stored in a plain text file with the
2.2. Tool Support
A feature is an executable specification through tool support. The execution either passes or fails, and a feature is completely implemented when all of its scenarios pass without failure. Through a proper BDD tool support, such as
Despite the multitude of target programming languages supported, each of the tools in the Gherkin family achieves executable specification in a way similar to what is described next.
Initially, when given a feature file as its input, a BDD tool generates a function (or an instance method) in the target language as the step definition for each different step inside the feature file. In all the aforementioned BDD tools, the tool-generated code for a step definition function prints a message to show that the step is not implemented yet. Developers and testers replace the generated code with: (1) code that calls the functions and object methods to be implemented for the feature; and (2) code that checks their correctness.
Assume that the step definition functions of a scenario are implemented. When tool is run again with the feature file containing the scenario as input, the steps in the scenarios are matched with its step definition functions, which are executed sequentially in the order of appearance. All existing tools adopt the sequential interpretation.
2.3. Failing-Fast
When a step in a scenario fails in execution, the scenario fails and terminates immediately, skipping the subsequent steps. This is referred to as failing-fast [31] and is the default behavior for all tools supporting Gherkin. The default behavior is sometimes inconvenient, (for example, in checking multiple independent post-conditions in separate
It is interesting to note that support for turning off failing-fast varies by tool. For example,
As will be shown in the two motivating examples in Section 3, the sequential interpretation of the steps in a scenario makes it difficult and sometimes impossible to specify concurrent behaviors in IoT and distributed systems. Further, in specifications that involve both concurrent and sequential behaviors, the description of the behaviors cannot be easily supported by simply turning off the failing-fast feature.
3. Two Motivating Examples
We present two motivating examples to argue for the need of supporting the specification of concurrent behaviors. Further, the supporting tool must properly allow turning off the failing-fast feature at the step level in the context of concurrency. The two examples, scheduled sprinkling (Section 3.1) and lift safety in emergency (Section 3.2), are kept simple but sufficient to reveal the problems the two core issues can cause.
3.1. Example: Scheduled Sprinkling
A lawn sprinkler system for home use is needed. Three sprinklers, each with a head connected by a pipe to a common water supply, are installed. Water emits from the sprinkler heads according to a schedule set by the owner through a controller. When it is time to sprinkle water, each sprinkler head begins emitting water within 5 s.
A plausible specification for capturing this requirement is by the Gherkin scenario of Figure 2. In this scenario, the three sprinklers have been set up (line 2), and the scheduled time has been set to 4:00:00 a.m. (line 3). When the scheduled time arrives (line 4), all three sprinklers should emit water within 5 s (lines 5, 6, and 7).
It should be clear from the problem statement that the three sprinklers should act concurrently; a failure in any of the three should not prevent the other two from exhibiting the required behavior. For instance, assume that the pipes branching off to sprinklers A and C, respectively, are clogged, but the pipe to sprinkler B is normal. When the scenario is executed, sprinkler A and sprinkler C should fail to emit water within 5 s (line 5 and line 7), whereas sprinkler B should emit water normally (line 6).
Under the current policy of the Gherkin language to interpret the steps sequentially and the policy of the existing supporting tools and to fail fast, the failure in the
It can be noted that turning off the failing-fast feature does not solve the problem either so long as the steps are interpreted sequentially. After sprinkler A fails, five seconds have already expired, causing the normal-functioning sprinkler B to fail. More of the anomaly introduced by the sequential interpretation of steps by Gherkin and the failing-fast feature of tool support will be discussed in Section 5.
On the other hand, the result of executing the scenario would reveal failures of sprinklers A and C and success of sprinkler B if the three assertions are executed concurrently. Further, the result remains so regardless of the failing-fast feature of the tool used.
3.2. Example: Lift Safety in Emergency
The next example is adapted from the problem descriptions in [35,36]:
A lift that guarantees safe operation is needed. Normally, the lift provides timely transport service to passengers by taking requests and stopping at the requested floors. However, in the case of an emergency, such as a power outage, a mechanical/electrical malfunction, or an earthquake, the lift must come to a full stop at the nearest floor in the direction of travel, open its doors and keep them open, give safety warnings across all floors, and cancel any outstanding requests.
In Figure 3, two scenarios are used to specify the requirements. The first scenario (lines 1–7) stipulates that when an emergency has been detected (line 3), the first
The first scenario specifies the “normal path” of the lift system’s response to an emergency. It should be kept in mind that it is possible for any step to fail. In the example, the lift can fail to stop at the first
It is not possible to fix the problem by turning off the failing-fast feature of the supporting tool used to run the scenario:
When the feature is turned off for the whole scenario, the two
And steps (lines 5–6) and theThen step (line 7) will be executed. The execution of the twoAnd steps are desirable and correctly checks the warning and cancellation of outstanding requests. Unfortunately, the checking of the lift doors of theThen step can be misleading: if it passes, the doors are open when the lift is either in motion or does not stop aligning with the landing, putting the passengers in danger; and if it fails, the doors are correctly closed for passenger safety;When the feature can be turned off at the step level, failing-fast at the first
Then step (line 4) must be turned off to guarantee execution of the warning and cancellation steps, but doing so could lead to the execution of checking lift doors and obtain a misleading result when the lift has failed to stop. On the other hand, keeping the failing-fast behavior prevents warning and cancellation steps if the firstThen step fails. Either way, potential safety checking omissions exist.
In summary, the checking of the lift doors of the
For the safety requirement to be completely specified, the second scenario (lines 9–12) is necessary. If the lift fails to stop properly at a floor in an emergency (lines 10–11), the lift doors must remain closed to keep the passengers safe (line 12), presumably to wait for rescue. Note how the situation is encoded in the
Table 1 lists the combinations of the states of the lift and the lift doors. The lift may or may not be stopped at the nearest floor, and the lift doors may be open or closed. The first scenario in Figure 3 (line 7) checks that the doors are open in success or closed in failure when the lift is stopped at the nearest floor. The second scenario (line 12) checks that the doors are closed in success or open in failure when the lift is not stopped at a floor. As can be seen in Table 1, all combinations of states of the lift and the doors are covered, and the safety requirement is fully specified by the two scenarios of Figure 3.
4. Concurrency Enhancement to Gherkin and Tool Support
We now propose a semantic enhancement of Gherkin to support specification of concurrent behaviors. In so doing, we adhere to the parsimony principle [20] to keep the enhancement minimal by not adding new keywords (Section 4.1). We also implemented a tool called
4.1. The Proposed Enhancement and Examples Resolved
Figure 4 shows the proposed enhancement in a class diagram. A feature contains one or more scenarios. A scenario is composed of one or more sequential groups that are executed in the order of appearance. Each sequential group has exactly one lead step, which can be a
With the enhancement, the scheduled sprinkling scenario of Figure 2 can now be interpreted correctly. The three steps of the
In the lift safety scenario of Figure 3, the three steps in the
Note that a failure at line 5 and line 6 causes the
4.2. Tool Support
The tool support of the proposed concurrency enhancement comes as an embedded domain specific language (DSL) [38]. It is named
Figure 5 shows the specification in
4.2.1. Executing a Scenario
Figure 7 presents the interactions taking place after calling the
To support the passing/failing semantics of a
4.2.2. Continuing Execution after a Step Fails
As pointed out in the lift example in Section 4.1, in addition to the proposed concurrency enhancement to Gherkin, a full resolution needs the supporting tool to turn off the failing-fast, which means to continue executing the remaining steps after the warning step or the cancellation step fails. Since continuation after failure is a feature that receives much debate [39], in adding this feature to
The continuation feature takes the form of an additional keyword argument to a step, continue_after_failure, which defaults to
5. Simulation Results
Through simulation, this section shows that both the concurrency enhancement of Gherkin and a tool support with the feature to continue execution after failure at the step level are necessary to enable correct specification and execution of concurrent behaviors in IoT systems. For comparison purposes, the simulations are also conducted with
5.1. Scheduled Sprinkling
The simulations of scheduled sprinkling of Figure 2 demonstrate the necessity to have concurrency support. Since a sprinkler head is supposed to emit water within 5 s after the scheduled time arrives, a delay of time in the sprinkler is used to simulate clogging: no clogging if the delay is well below 5 s and clogging otherwise. Recall that all three sprinklers are supposed to act independently and simultaneously. Thus, our objective is to observe if clogging in any sprinkler incorrectly affects the checking of the behaviors of the remaining normal sprinklers.
The results are shown in Table 2 and Table 3 with
In each table, three sets of simulations are conducted, each of which is repeated 100 times. Simulation 1 shows the results for the normal case using delays that are well under 5 s for all three sprinklers. Simulation 2 simulates clogging of sprinkler A by setting its delay to 5.05 s, while the remaining sprinklers are normal. Simulation 3 simulates the edge case of near-clogging of sprinkler A by setting its delay to 4.99 s, which is just under but very close to 5 s; the remaining sprinklers are normal.
Table 2 shows the simulation results for
Table 3 shows the simulation results for
5.2. Lift Safety over Service in Emergency
Simulations for the lift safety example demonstrate that concurrency enhancement alone is not enough; the supporting tool must also provide the feature to continue executing the specification after a failure at the step level.
The simulations are limited to the first lift scenario in Figure 3. We assume that the
Results of the three sets of simulations are shown in Table 4, Table 5, and Table 6, respectively. In each table, the four columns under the title Execution Result show the states for the steps at lines 4, 5, 6, and 7, respectively, as being executed (passing or failing) or skipped, respectively. The last column indicates whether the steps are executed/skipped correctly (marked by “✓”) or incorrectly (marked by “✗”). The correct behaviors are summarized below:
Checking of lift doors opening should be executed (line 7) only when the lift stops at the nearest floor (line 4);
Checking of lift doors opening should be skipped (line 7) if the lift fails to stop at a floor (line 4);
Regardless of the lift stopping or not (line 4), checking of warning (line 5) and checking of request canceling (line 6) are always executed.
Table 4 shows the simulation results in
Table 5 shows the simulation results in
Table 6 shows the simulation results obtained by executing the specification of Figure 9 with
6. Consequences and Related Issues
The proposed concurrency enhancement of Gherkin and the tool
6.1. Compatibility in Style
In the proposed enhancement, the keywords
6.2. Collocating Specification and Continuation after Failure Settings
The proposed tool
6.3. Implementation Level Concurrency
Let it be said out front that concurrency is completely feasible with a tool such as
Figure 11 shows the step definition function of the
However, the step definition of Figure 11 has the following limitations:
Lumping the concurrent steps of the
Then group of Figure 2 into one step hides the specific point of failure: when the step fails, it would only be possible to know that one of the sprinklers had failed but not which one had failed. This hampers the task of diagnosis;The level of abstraction is lowered from the specification level to the step definition at the implementation level. Specifically, unless the domain expert or analyst is comfortable working with code (and
Thread in particular), he or she will have to depend on the developer or tester to translate the step at line 5 of Figure 10. In other words, the domain expert or analyst is deprived of his or her place to specify concurrent behaviors. Such delegated translation is exactly what BDD tries to eliminate as it creates gaps in communication [40];If the step fails, it is not directly possible for
behave to report the error due to the use ofThread .
7. Conclusions
Behavior-driven development (BDD) has brought the benefits of ubiquitous language, executable specification, and living documentation to mainstream software development. In order to bring these benefits to the development of the inherently concurrent Internet of Things (IoT) systems, it is necessary to have good support in the specification and execution of concurrent behaviors in IoT systems. Our contribution in this paper is to demonstrate that the current BDD specification language Gherkin and its associated tools are inadequate to the specification and execution of concurrent behaviors and proposed an enhancement to Gherkin and developed a supporting tool accordingly.
The enhancement to the Gherkin language introduces sequential groups of concurrent steps. Each group is led off with a step that begins with keyword
In our future work, we plan to explore the use of sequential groups of concurrent steps in the context of
Conceptualization, B.-Y.W., Y.-C.Y. and Y.C.C.; software, B.-Y.W., Y.-C.Y. and Y.C.C.; writing—original draft preparation, B.-Y.W., Y.-C.Y. and Y.C.C.; writing—review and editing, B.-Y.W., Y.-C.Y. and Y.C.C.; supervision, Y.C.C.; funding acquisition, Y.C.C. All authors have read and agreed to the published version of the manuscript.
Not applicable.
Not applicable.
No new data were created or analyzed in this study. Data sharing is not applicable to this article.
The authors declare no conflict of interest.
Footnotes
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.
Figure 3. Lift operations: safety over serving normal requests in case of an emergency.
Figure 4. The proposed enhancement to Gherkin for specifying both sequential and concurrent behaviors.
Figure 6. Default step definition of the scheduled sprinkling scenario generated in scheduled_sprinkling.py.
Figure 7. Sequence diagram of calling the execute method of the scheduled sprinkling scenario in concurrentSpec.
Figure 8. Screen dump of the scheduled sprinkling scenario with both sprinklers A and C clogged.
Figure 9. Scenario of emergency braking and warning over normal requests in concurrentSpec.
Figure 10. Scheduled sprinkling with behave: lumping three concurrent behaviors into one step.
Figure 11. Scheduled sprinkling with behave: implementing concurrency in a step definition.
All combinations of states of the lift and the doors in checking safety.
Lift | Lift Doors | Covered by Which Result in |
---|---|---|
stopped | open | passing at line 7 |
stopped | closed | failing at line 7 |
not stopped | open | failing at line 12 |
not stopped | closed | passing at line 12 |
Simulation results of executing the scheduled sprinkling specification in
Simulation | Delay (Seconds) | ( |
Result Correct? | ||||
---|---|---|---|---|---|---|---|
A | B | C | A | B | C | ||
1 | 0.2 | 0.5 | 0.3 | (100, 0, 0) | (100, 0, 0) | (100, 0, 0) | ✓ |
2 | 5.05 | 0.5 | 0.3 | (0, 100, 0) | (0, 0, 100) | (0, 0, 100) | ✗ |
3 | 4.99 | 0.5 | 0.3 | (10, 90, 0) | (9, 1, 90) | (8, 1, 91) | ✗ |
Simulation results of executing the scheduled sprinkling specification in
Simulation | Delay (Seconds) | ( |
Result Correct? | ||||
---|---|---|---|---|---|---|---|
A | B | C | A | B | C | ||
1 | 0.2 | 0.5 | 0.3 | (100, 0, 0) | (100, 0, 0) | (100, 0, 0) | ✓ |
2 | 5.05 | 0.5 | 0.3 | (0, 100, 0) | (100, 0, 0) | (100, 0, 0) | ✓ |
3 | 4.99 | 0.5 | 0.3 | (50, 50, 0) | (100, 0, 0) | (100, 0, 0) | ✓ |
Simulation results of executing the lift safety specification in
Simulation | Execution Result | Result Correct? | |||
---|---|---|---|---|---|
Lift Is Stopped |
Emergency Indicator Is on |
Request Is Canceled (Line 6) | Lift Doors Are Open (Line 7) | ||
1 | executed-passing | executed-passing | executed-passing | executed | ✓ |
2 | executed-passing | executed-passing | executed-failing | skipped | ✗ |
3 | executed-passing | executed-failing | skipped | skipped | ✗ |
4 | executed-failing | skipped | skipped | skipped | ✗ |
Simulation results of executing the lift safety specification in
Simulation | Execution Result | Result Correct? | |||
---|---|---|---|---|---|
Lift Is Stopped |
Emergency Indicator Is on (Line 5) | Request Is Canceled (Line 6) | Lift Doors Are Open (Line 7) | ||
1 | executed-passing | executed-passing | executed-passing | executed | ✓ |
2 | executed-passing | executed-passing | executed-failing | executed | ✓ |
3 | executed-passing | executed-failing | executed-passing | executed | ✓ |
4 | executed-passing | executed-failing | executed-failing | executed | ✓ |
5 | executed-failing | executed-passing | executed-passing | executed | ✗ |
6 | executed-failing | executed-passing | executed-failing | executed | ✗ |
7 | executed-failing | executed-failing | executed-passing | executed | ✗ |
8 | executed-failing | executed-failing | executed-failing | executed | ✗ |
Simulation results of executing the lift safety specification in
Simulation | Execution Result | Result Correct? | |||
---|---|---|---|---|---|
Lift Is Stopped |
Emergency Indicator Is on (Line 5) | Request Is Canceled (Line 6) | Lift Doors Are Open (Line 7) | ||
1 | executed-passing | executed-passing | executed-passing | executed | ✓ |
2 | executed-passing | executed-passing | executed-failing | executed | ✓ |
3 | executed-passing | executed-failing | executed-passing | executed | ✓ |
4 | executed-passing | executed-failing | executed-failing | executed | ✓ |
5 | executed-failing | executed-passing | executed-passing | skipped | ✓ |
6 | executed-failing | executed-passing | executed-failing | skipped | ✓ |
7 | executed-failing | executed-failing | executed-passing | skipped | ✓ |
8 | executed-failing | executed-failing | executed-failing | skipped | ✓ |
References
1. Jacobson, I.; Spence, I.; Ng, P.W. Is there a single method for the internet of things?. Commun. ACM; 2017; 60, pp. 46-53. [DOI: https://dx.doi.org/10.1145/3106637]
2. Merzouk, S.; Cherkaoui, A.; Marzak, A.; Nawal, S. IoT methodologies: Comparative study. Procedia Comput. Sci.; 2020; 175, pp. 585-590. [DOI: https://dx.doi.org/10.1016/j.procs.2020.07.084]
3. Kaisti, M.; Rantala, V.; Mujunen, T.; Hyrynsalmi, S.; Könnölä, K.; Mäkilä, T.; Lehtonen, T. Agile methods for embedded systems development-a literature review and a mapping study. EURASIP J. Embed. Syst.; 2013; 2013, 15. [DOI: https://dx.doi.org/10.1186/1687-3963-2013-15]
4. Berg, V.; Birkeland, J.; Nguyen-Duc, A.; Pappas, I.O.; Jaccheri, L. Achieving agility and quality in product development-an empirical study of hardware startups. J. Syst. Softw.; 2020; 167, 110599. [DOI: https://dx.doi.org/10.1016/j.jss.2020.110599]
5. Nguyen-Duc, A.; Khalid, K.; Shahid Bajwa, S.; Lønnestad, T. Minimum viable products for internet of things applications: Common pitfalls and practices. Future Internet; 2019; 11, 50. [DOI: https://dx.doi.org/10.3390/fi11020050]
6. North, D. Introducing BDD. Available online: https://dannorth.net/introducing-bdd/ (accessed on 27 February 2022).
7. Beck, K. Test-Driven Development: By Example; Addison-Wesley Professional: Boston, MA, USA, 2003.
8. Pascal, A. State of Behavior Driven Development 2018—The Results!. Available online: https://cucumber.io/blog/bdd/state-of-behavior-driven-development-2018-the-resu/ (accessed on 9 December 2022).
9. Adzic, G. Specification by Example: How Successful Teams Deliver the Right Software; Simon and Schuster: New York, NY, USA, 2011.
10. Smart, J. BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle; Manning: Greenwich, CT, USA, 2014.
11. Lawrence, R.; Rayner, P. Behavior-Driven Development with Cucumber: Better Collaboration for Better Software; Addison-Wesley Professional: Hoboken, NJ, USA, 2019.
12. Nicieja, K. Writing Great Specifications: Using Specification by Example and Gherkin; Simon and Schuster: New York, NY, USA, 2017.
13. The Ultimate Guide to BDD Test Automation Frameworks. Available online: https://cucumber.io/blog/bdd/the-ultimate-guide-to-bdd-test-automation-framewor/ (accessed on 15 December 2022).
14. Nezhad, A.S.; Lukkien, J.J.; Mak, R.H. Behavior-Driven Development for Real-Time Embedded Systems. Proceedings of the 2018 IEEE 23rd International Conference on Emerging Technologies and Factory Automation (ETFA); Turin, Italy, 4–7 September 2018; Volume 1, pp. 59-66. [DOI: https://dx.doi.org/10.1109/ETFA.2018.8502653]
15. Wiecher, C.; Japs, S.; Kaiser, L.; Greenyer, J.; Dumitrescu, R.; Wolff, C. Scenarios in the loop: Integrated requirements analysis and automotive system validation. MODELS ’20, Proceedings of the 23rd ACM/IEEE International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings, Virtual Event, 16–23 October 2020; Association for Computing Machinery: New York, NY, USA, 2020; pp. 1-10. [DOI: https://dx.doi.org/10.1145/3417990.3421264]
16. Wiecher, C.; Fischbadh, J.; Greenyer, J.; Vogelsang, A.; Wolff, C.; Dumitrescu, R. Integrated and Iterative Requirements Analysis and Test Specification: A Case Study at Kostal. Proceedings of the 2021 ACM/IEEE 24th International Conference on Model Driven Engineering Languages and Systems (MODELS); Fukuoka, Japan, 10–15 October 2021; pp. 112-122. [DOI: https://dx.doi.org/10.1109/MODELS50736.2021.00020]
17. Zaeske, W.; Durak, U.; Torens, C. Behavior Driven Development for Airborne Software Engineering. Proceedings of the AIAA Scitech 2021 Forum; Virtual Event, 11–15 January 2021; 19–21 January 2021; 1917. [DOI: https://dx.doi.org/10.2514/6.2021-1917]
18. Yen, Y.C.; Wang, B.Y.; Zhong, X.Z.; Chiang, W.Y.; Hsieh, C.Y.; Cheng, Y.C. Applying Problem Frames in Behavior-Driven Development for Smart Cone System. Proceedings of the 2021 28th Asia-Pacific Software Engineering Conference (APSEC); Taipei, Taiwan, 6–9 December 2021; pp. 566-567. [DOI: https://dx.doi.org/10.1109/APSEC53868.2021.00070]
19. Gherkin Reference. Available online: https://cucumber.io/docs/gherkin/reference/ (accessed on 27 February 2022).
20. Bentley, J.L. Little languages. Commun. ACM; 1986; 29, pp. 711-721. [DOI: https://dx.doi.org/10.1145/6424.315691]
21. concurrentSpec. Available online: https://github.com/benny870704/concurrentSpec (accessed on 4 January 2023).
22. Janzen, D.; Saiedian, H. Test-driven development concepts, taxonomy, and future direction. Computer; 2005; 38, pp. 43-50. [DOI: https://dx.doi.org/10.1109/MC.2005.314]
23. Turhan, B.; Layman, L.; Diep, M.; Erdogmus, H.; Shull, F. How effective is test-driven development. Making Software: What Really Works, and Why We Believe It; O’Reilly Media, Inc.: Sebastopol, CA, USA, 2010; pp. 207-217.
24. Moe, M.M. Comparative Study of Test-Driven Development TDD, Behavior-Driven Development BDD and Acceptance Test–Driven Development ATDD. Int. J. Trend Sci. Res. Dev.; 2019; 3, pp. 231-234. [DOI: https://dx.doi.org/10.31142/ijtsrd23698]
25. Behaviour-Driven Development. Available online: https://cucumber.io/docs/bdd/ (accessed on 23 September 2022).
26. Bellware, S. Behavior-Driven Development. Available online: https://www.codemag.com/article/0805061 (accessed on 25 September 2022).
27. Apel, S.; Kästner, C. An overview of feature-oriented software development. J. Object Technol.; 2009; 8, pp. 49-84. [DOI: https://dx.doi.org/10.5381/jot.2009.8.5.c5]
28. Cucumber. Available online: https://cucumber.io/docs/guides/overview/ (accessed on 7 September 2022).
29. Behave. Available online: https://behave.readthedocs.io/en/stable/index.html (accessed on 12 March 2022).
30. SpecFlow. Available online: https://specflow.org/ (accessed on 7 September 2022).
31. Shore, J. Fail Fast [Software Debugging]. IEEE Softw.; 2004; 21, pp. 21-25. [DOI: https://dx.doi.org/10.1109/MS.2004.1331296]
32. Behave-Option: Continue after Failed Step in a Scenario. Available online: https://python-behave.readthedocs.io/en/latest/new_and_noteworthy_v1.2.6.html#option-continue-after-failed-step-in-a-scenario (accessed on 30 October 2022).
33. Cucumber—How Can I Make Cucumber Run the Skipped Steps after a Failed Step. Available online: https://cucumber.io/docs/community/faq/?lang=java#how-can-i-make-cucumber-run-the-skipped-steps-after-a-failed-step (accessed on 7 November 2022).
34. Cucumber-JVM Fork to Continue Next Steps for Some Exceptions + Run Scenarios in Parallel. Available online: https://github.com/slaout/cucumber-jvm (accessed on 2 November 2022).
35. Jackson, M. Software Requirements & Specifications: A Lexicon of Practice, Principles and Prejudices; ACM Press/Addison-Wesley Publishing Co.: Reading, MA, USA, 1995; pp. 126–127, 169.
36. Jackson, M. Problem Frames: Analysing and Structuring Software Development Problems; Addison-Wesley: Reading, MA, USA, 2001; pp. 28–29, 319–320.
37. Shrestha, A. Safety Considerations for the Design of Modern Elevator Systems. Undergraduate. Honors Thesis; University of Mississippi: University, MS, USA, 2019.
38. Mernik, M.; Heering, J.; Sloane, A.M. When and how to develop domain-specific languages. ACM Comput. Surv. (CSUR); 2005; 37, pp. 316-344. [DOI: https://dx.doi.org/10.1145/1118890.1118892]
39. Being Able to Continue Next Steps on @Then Failures. Available online: https://github.com/cucumber/common/issues/79 (accessed on 4 January 2023).
40. Adzic, G. Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing; Neuri Limited: London, UK, 2009.
You have requested "on-the-fly" machine translation of selected content from our databases. This functionality is provided solely for your convenience and is in no way intended to replace human translation. Show full disclaimer
Neither ProQuest nor its licensors make any representations or warranties with respect to the translations. The translations are automatically generated "AS IS" and "AS AVAILABLE" and are not retained in our systems. PROQUEST AND ITS LICENSORS SPECIFICALLY DISCLAIM ANY AND ALL EXPRESS OR IMPLIED WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES FOR AVAILABILITY, ACCURACY, TIMELINESS, COMPLETENESS, NON-INFRINGMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Your use of the translations is subject to all use restrictions contained in your Electronic Products License Agreement and by using the translation functionality you agree to forgo any and all claims against ProQuest or its licensors for your use of the translation functionality and any output derived there from. Hide full disclaimer
© 2023 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/). Notwithstanding the ProQuest Terms and Conditions, you may use this content in accordance with the terms of the License.
Abstract
The Internet of Things (IoT) systems are inherently distributed with many concurrent behaviors. In order to apply behavior-driven development (BDD), a proven agile practice of software development that brings many benefits, we must ensure that the specification of sequential and concurrent behaviors is supported at the specification level and that tool support is in place to execute the specification. This study proposes a minimal semantic enhancement to the Gherkin language, the most popular specification language in BDD, to distinguish sequential and concurrent behaviors. At the same time, a tool called
You have requested "on-the-fly" machine translation of selected content from our databases. This functionality is provided solely for your convenience and is in no way intended to replace human translation. Show full disclaimer
Neither ProQuest nor its licensors make any representations or warranties with respect to the translations. The translations are automatically generated "AS IS" and "AS AVAILABLE" and are not retained in our systems. PROQUEST AND ITS LICENSORS SPECIFICALLY DISCLAIM ANY AND ALL EXPRESS OR IMPLIED WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES FOR AVAILABILITY, ACCURACY, TIMELINESS, COMPLETENESS, NON-INFRINGMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Your use of the translations is subject to all use restrictions contained in your Electronic Products License Agreement and by using the translation functionality you agree to forgo any and all claims against ProQuest or its licensors for your use of the translation functionality and any output derived there from. Hide full disclaimer