Adapting Behavior Driven Development (BDD) for large-scale software systems (original) (raw)

Towards a Taxonomy for Applying Behavior-Driven Development (BDD)

2019

Behavior-Driven Development (BDD) is a topic currently much talked about, especially in the agile community. Small scale examples of BDD suggest an intuitive and easy use, but experience shows that in practice, especially large projects, its application becomes elaborate and challenging. This paints an inconsistent picture about BDD. So, what are the requirements for a successful application of BDD? We have identi ed, discussed, and classi ed the core aspects of applying BDD. Depending on the application context, an aspect can speak for or against the use of BDD. These aspects and their pro and contra arguments are this article's main contribution. Everyone can use these aspects to decide whether and how to use BDD in their individual project context.

A Study of the Characteristics of Behaviour Driven Development

2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications, 2011

Behaviour Driven Development (BDD) has gained increasing attention as an agile development approach in recent years. However, characteristics that constituite the BDD approach are not clearly defined. In this paper, we present a set of main BDD charactersitics identified through an analysis of relevant literature and current BDD toolkits. Our study can provide a basis for understanding BDD, as well as for extending the exisiting BDD toolkits or developing new ones.

A Study of Framework of Behavioural Driven Development: Methodologies, Advantages, and Challenges

International Journal on Future Revolution in Computer Science & Communication Engineering

BDD is the behavioural driven development which is used for the development process of the software. It used to describe behaviour of the system in a language which is easy to read and understand. It is the development process which is used to bridge the gap between the technical people involved in the project and the businesspeople who are not technically sound. The aim and goal of BDD is to deliver business value products for which it helps to provide communication between developers and analysts via shared process and tools. The origin of BDD is TDD which is test driven development where examples are used to describe the behaviour of the system which could be used as acceptance test, and which could be converted into executable specifications. This process is very useful for the software developers as it is very useful for them to develop a software project which fulfils all its goals and aim. This methodology also helps to get rid of the confusion and improves the communication ...

Maintaining Behaviour Driven Development Specifications: Challenges and Opportunities

In Behaviour-Driven Development (BDD) the behaviour of a software system is specified as a set of example interactions with the system using a “Given-When-Then” structure. These examples are expressed in high level domain-specific terms, and are executable. They thus act both as a specification of requirements and as tests that can verify whether the current system implementation provides the desired behaviour or not. This approach has many advantages but also presents some problems. When the number of examples grows, BDD specifications can become costly to maintain and extend. Some teams find that parts of the system are effectively frozen due to the challenges of finding and modifying the examples associated with them. We surveyed 75 BDD practitioners from 26 countries to understand the extent of BDD use, its benefits and challenges, and specifically the challenges of maintaining BDD specifications in practice. We found that BDD is in active use amongst respondents, and that the use of domain specific terms, improving communication among stakeholders, the executable nature of BDD specifications, and facilitating comprehension of code intentions are the main benefits of BDD. The results also showed that BDD specifications suffer the same maintenance challenges found in automated test suites more generally. We map the survey results to the literature, and propose 10 research opportunities in this area.

Characterising the Quality of Behaviour Driven Development Specifications

Characterising the Quality of Behaviour Driven Development Specifications, 2020

Behaviour Driven Development (BDD) is an agile testing technique that enables software requirements to be specified as example interactions with the system, using structured natural language. While (in theory) being readable by non-technical stakeholders, the examples can also be executed against the code base to identify behaviours that are not yet correctly implemented. Writing good BDD suites, however, is challenging. A typical suite can contain hundreds of individual scenarios, that must correctly specify the system as a whole as well as individually. Despite much discussion amongst practitioners and in the blogosphere, as yet no formal definition of what makes for a high quality BDD suite has been given. To shed light on this, we surveyed BDD practitioners, asking for their opinions on the quality criteria that are important for BDD suites. We proposed, and asked for opinions on, four quality principles, and gave practitioners the option to add more principles of their own. This paper reports on the results of the survey, and presents an approach to defining BDD suite quality.

Implementing Behavior Driven Development in an Open Source ERP

Lecture Notes in Business Information Processing, 2013

A typical problem in Software Engineering is how to guarantee that all system's requirements are correctly implemented through source code. Traditionally, requirement tracing is a manual task comprised of keeping links from requirements to source code, going through different modeling artifacts, including models. However, these techniques cannot guarantee that requirements are always correctly implemented by source code. Aiming at solving this problem, Behavior-Driven Development (BDD) is a specification technique that automatically checks if all functional requirements are treated properly by source code through the connection of the textual description of requirements to automated tests. Given that for Enterprise Information Systems, requirements are usually identified by analyzing business process models, and these processes are implemented through workflows, connecting workflows to automated tests through BDD specifications can provide automated requirements traceability. The aim of this paper is to briefly present this proposal and show how it was implemented for the open source ERP5 system.

Bridging the Gap between Requirements Modeling and Behavior-Driven Development

2019 ACM/IEEE 22nd International Conference on Model Driven Engineering Languages and Systems (MODELS)

Acceptance criteria (AC) are implementation agnostic conditions that a system must meet to be consistent with its requirements and be accepted by its stakeholders. Each acceptance criterion is typically expressed as a naturallanguage statement with a clear pass or fail outcome. Writing AC is a tedious and error-prone activity, especially when the requirements specifications evolve and there are different analysts and testing teams involved. Analysts and testers must iterate multiple times to ensure that AC are understandable and feasible, and accurately address the most important requirements and workflows of the system being developed. In many cases, analysts express requirements through models, along with natural language, typically in some variant of the UML. AC must then be derived by developers and testers from such models. In this paper, we bridge the gap between requirements models and AC by providing a UML-based modeling methodology and an automated solution to generate AC. We target AC in the form of Behavioral Specifications in the context of Behavioral-Driven Development (BDD), a widely used agile practice in many application domains. More specially we target the well-known Gherkin language to express AC, which then can be used to generate executable test cases. We evaluate our modeling methodology and AC generation solution through an industrial case study in the financial domain. Our results suggest that (1) our methodology is feasible to apply in practice, and (2) the additional modeling effort required by our methodology is outweighed by the benefits the methodology brings in terms of automated and systematic AC generation and improved model precision.

Behavior-Driven Development in Product Configuration Systems (short paper)

International Configuration Workshop, 2018

1 Product Configuration Systems (PCS) are increasingly used by companies to automate the performance of the sales and engineering processes. Since the benefits from such projects have huge variations, it is crucial to make the right decisions when scoping and developing PCSs. The development of PCS is influenced by both business interests and technical insights. Developers of PCS face various challenges while working in team, including different stakeholders such as business owners, developers, project managers, and product experts. The more diverse the team is, the more significant are the challenges. This paper suggests that Behavior-driven Development (BDD) may provide configuration teams with a specific structure to express scenarios (and thus constraints) on PCS in natural language. BDD may yield benefits such as a better expression of PCS constraints, more efficient communication of requirements and incorporation of the expressed rules in a software transformation process. In other words, applying BDD may eliminate unnecessary tasks when gathering knowledge, developing, and testing PCS projects. In this paper, we present a novel approach from an ongoing project on how to relate BDD to the development process of PCS while using Scrum-based methods.

Filling the gap between business process modeling and behavior driven development - 1005.4975

Firstly a historical perspective of the evolution of previous proposals from which this one emerged will be presented, and then the reasons to change from Model Driven Development (MDD) to BDD will be presented also in a historical perspective. Finally the proposal of using FSM, specifically by using UML Statechart diagrams, will be presented, followed by some conclusions.

Behavior-Driven Development in Product Configuration Systems

2018

1 Product Configuration Systems (PCS) are increasingly used by companies to automate the performance of the sales and engineering processes. Since the benefits from such projects have huge variations, it is crucial to make the right decisions when scoping and developing PCSs. The development of PCS is influenced by both business interests and technical insights. Developers of PCS face various challenges while working in team, including different stakeholders such as business owners, developers, project managers, and product experts. The more diverse the team is, the more significant are the challenges. This paper suggests that Behavior-driven Development (BDD) may provide configuration teams with a specific structure to express scenarios (and thus constraints) on PCS in natural language. BDD may yield benefits such as a better expression of PCS constraints, more efficient communication of requirements and incorporation of the expressed rules in a software transformation process. In ...