Goals of Behavior Testing Framework

Behavior Testing Framework was designed to support several goals.

Support for Behavior-Driven Development

Behavior-Driven Development (BDD) is a software development approach where the focus is placed on describing user behavior and verifying that the software produces the expected results from that behavior. Ideally, you write these descriptions of behavior before the software is developed, as well as tests that verify the behavior. Initially, the tests will fail because the functionality has not yet been implemented. As functionality is developed, the tests pass. This ensures the software supports the desired behaviors.

Behavior-Driven Development emphasizes collaboration between business resources and technical resources. A fundamental belief is that software development is more effective and more efficient when the stakeholders and the agile team discuss requirements using a common language.

  • Analysts contribute by analyzing their business and communicating the business behavior expected from the application.
  • Software developers and QA developers contribute by clarifying the technical implementation on the user behavior and implementing the step definitions

In Behavior-Driven Development, software behaviors are written as a set of scenarios. Each scenario describes user behavior and its impact on the state of the system.

Behavior Testing Framework supports this goal in the context of InsuranceSuite by providing an integration with Cucumber and enhancing the GUnit framework, a tool that reads executable specifications written in natural language.

Separation of business details from implementation details

Some testing frameworks use a single layer of resources to define testing requirements. This approach tends to be highly technical. As a result, business experts are forced to play a secondary role in testing development because they do not usually express business requirements in a highly technical manner.

Behavior Testing Framework uses multiple layers of resources. This includes:

  • The business layer, which consists primarily of scenarios. Scenarios are written in Gherkin, an executable language that reads like natural language. Both business experts and technical experts can write scenarios in Gherkin.
  • The context implementation layer, which consists primarily of Gosu classes that specify implementation details in a highly technical manner.
  • The mapping layer, which connects the business layer and the context implementation layer, and provides the freedom to modify resources in one layer without needing to make changes to resources in the other layer.

Sharing and isolating implementations

In some circumstances, different scenarios must perform a given action in the same way. For example, consider the action of assigning a user to a group. This action is always performed in the same way, regardless of the scenario that executes it.

In other circumstances, different scenarios must perform a given action in different ways. For example, consider the action of adding an optional coverage during a submission. The possible values vary based on the policy's type of product. In other words, this action is performed in different ways, depending on the scenario that executes it.

Behavior Testing Framework is designed to support both of these use cases. When a test step behaves the same way in all circumstances, all scenarios using this test step execute the same implementation code. When a test step must behave differently based on the scenario, multiple implementations exist, and Behavior Testing Framework selects the correct implementation for each scenario.

Provide for easy extensibility

Behavior Testing Framework comes with a set of business scenarios and implementations to test these scenarios. These resources provide examples for how to write and implement scenarios. They are based on the base configuration of PolicyCenter, and all scenarios will pass when run against the base configuration.

However, during an implementation of PolicyCenter, insurers configure the application to meet their business needs. Behavior Testing Framework can similarly be modified to test an insurer's configurations.

  • New scenarios can be added.
  • New implementation resources can be added.
  • Existing implementation resources can be extended.
  • New implementation strategies can be added, such as conducting tests with REST APIs.