Blog

CBA staff leasing: Fairness for temporary workers and security for staff leasing agencies

Read more
Engineering

Behavior Driven Development

At Apriko, we strive for a high degree of automation of customer processes, a fast market launch, and continuous improvement of our software. To ensure this in a demanding domain and complex software architecture, precise planning and consistent implementation from the outset are essential.

Read more

Behavior Driven Development – our driver for innovation and progress

Engineering
August 12, 2024

At Apriko, we strive for a high degree of automation of customer processes, a fast market launch, and continuous improvement of our software. To ensure this in a demanding domain and complex software architecture, precise planning and consistent implementation from the outset are essential.

Software regressions – a barrier to innovation

In today’s software development, teams face the challenge of ensuring that their systems work seamlessly with different, often complex processes and logics. These systems must also be compatible with a variety of software solutions that are updated regularly. However, with these updates, there is a risk that previously smoothly functioning processes suddenly no longer run properly due to changes in the source code.

These software regressions can occur when new functions are added, software updates are installed, or previous errors are fixed. As software and interfaces continue to evolve, the risk that any change will cause unexpected problems increases.

Several factors significantly exacerbate the problem of software regressions: Loss of knowledge, rapidly changing technologies, and a growing code base make it difficult for developers to fully predict all the effects of a change. This leads to reluctance for optimizations and replacing outdated software components.

This often results in an extended test duration that can lead to even minor changes that require several months of test time. In extreme cases, this can go so far that hardly any changes or new functions are developed, as the effort for testing and validation is disproportionately high. This significantly limits the innovative power of software development.

Behavior Driven Development – automated testing and clear communication

At Apriko, we rely on the Behavior Driven Development (BDD) approach. The goal of behaviour-driven software development is to simplify collaboration between the development team and the business by means of a common language. This creates a uniform understanding and automates testing.

The behaviour of the application methodically controls the design process. The ubiquitous language translates this behaviour into elements that allow analysis of the code and subsequent acceptance tests before the software is finished. Automating testing improves quality assurance and speeds time to market.

The BDD approach is based on a domain-specific syntax that is often exemplified by the Gherkin format. This syntax follows the “given-when-then” model:

  • Given: The initial conditions for the test.
  • When: The steps that are performed during the test.
  • Then: The results that need to be checked to ensure that the software is showing the desired behaviour.

The advantage of BDD is that the software is not described by extensive and complex specifications but by clear, understandable examples. These are formulated in such a way that they are comprehensible for all parties involved and misunderstandings are largely ruled out. The examples are structured in such a way that they can be transferred directly to automated acceptance tests.

In the .NET environment, BDD is often supported by SpecFlow. SpecFlow makes it possible to translate natural language software criteria that are documented in feature files according to the Gherkin syntax into executable code. This simplifies the execution of automated tests and provides a transparent overview of the test status – whether tests were successful, failed or have not yet been implemented. This provides developers with accurate and up-to-date documentation of the software status and acceptance criteria, which effectively eliminates uncertainties regarding erroneous behaviour or outdated documentation.

Complexity reduction, clear interfaces, and decoupling

We take an API-first approach with the API as the focus. Before we implement a user story or write a line of code, the complete behaviour – including positive cases, error cases, validations, operations, and known boundary cases – is designed and specified in feature files in the Gherkin format.
In order to make the common language as efficient as possible, we have defined specific steps and uniformly implemented the behaviour of these steps. This allows us to automate tests based on the specifications without writing a line of test code.

With these standardised elements, all conceivable API behaviours can be defined and checked.

From the operations steps (When) in the specification, we generate HTTP requests and use the HTTP response for validation in the review steps (Then). The tables contained in the specification are transferred to the payload for the HTTP requests, while the tables from the review steps are serialised accordingly to compare the response content. We convert the tables to the required formats such as JSON, XML, etc.

We also use standardised steps to compare our CSV, PDF, or Word export content, for example, or to mock or simulate external APIs.

To ensure that the scenarios and the subsequent tests in one service are not dependent on other services, we have developed a step with which we can place an event message in the event bus.

This enables us to view the message as an interface to other services in the tests and in the design without having to know details about other domains or services. This reduces complexity, defines a clear interface, and further ensures decoupling.

For each scenario, an isolated environment including a database with the current code status of the software is automatically provided. HTTP requests are generated from the syntax written in Gherkin as described above and checked against our API in the sense of a blackbox test.

The tests run fully automatically with every code change after the classic unit tests, and we receive feedback within 15 minutes whether we have caused regressions. Several thousand scenarios are executed in just a few minutes, and all functions are fully tested for their behaviour. If there are no regressions and a feature has passed our other quality requirements, such as code review or exploratory testing, it can be rolled out to production at the push of a button. In our overall architecture, which is based on microservices and model-driven architecture with in-house developed code generators, the specification accounts for eighty percent of the total code base. This is a remarkable result and underlines the effectiveness of our design approaches and their implementation.

Conclusion: Behavior Driven Development – a sophisticated path to sustainable success

Behavior Driven Development is a real game changer when applied correctly and consistently. However, the associated effort should not be underestimated and should be planned carefully, whereby management support is also essential. The consistent creation of the specification as a requirement and design artefact serves as a driver for downstream development. Creating at this level of detail is an abstract and demanding job that requires experienced developers with the right skills. It is important to follow the chosen path consistently; gaps in the specification significantly reduce the meaningfulness of the regression tests. However, investing in this approach quickly pays off in the form of long-lasting products and can provide a real competitive advantage.

Curious? Then get in touch with us!

Thaya Selvarajah
Product owner & Solution Architect

More good reasons for Apriko

Engineering

Reach your target faster and better: With automated code generation

August 12, 2024

Complexity is high in modern software development, especially in microservices architectures. But what do you do to avoid errors in simple and repetitive tasks?

Engineering

Platform for modern enterprise applications

August 12, 2024

Apriko was developed as a microservice application to meet the increasing requirements of modern enterprise applications. This architecture approach provides the agility, scalability, and maintainability required by today’s software systems. It has proven its worth with major software companies such as LinkedIn, Spotify, and Netflix.

Engineering

Automatic generation of the graphic user interface (UI)

August 12, 2024

A central design principle of Apriko’s software architecture is to automatically generate as much boilerplate code as possible or to derive logic. This allows the development team to focus more on the “what” and less on the “how” (the time-consuming detail work).

Job

Full Stack Engineer

April 10, 2024

As a member of an agile Kanban team, you drive the domain forward and shape the vision, roadmap, and features. You implement features from backend to frontend, actively shape the process, and further develop services, APIs, and engines for backend, API, and web UI generation. You conceptualize and implement software infrastructure requirements with a focus on clean code, good performance, and high test coverage.

Engineering

DevOps at Apriko

August 12, 2024

The development of modern software requires agile methods in order to be able to react quickly to market changes and ensure quality at the same time. DevOps offers the ideal solution here thanks to the close integration of development and operation.

Duration: 9 Minutes
Author: Thaya Selvarajah

This website uses cookies to analyze usage for improvements. You can disable cookies in your browser settings, but doing so may affect website functionality.

Share Options

Share interesting content and useful information.