Language-Agnostic Test Data Environment for Software Testing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Software testing, particularly in test-driven development (TDD), faces challenges due to the need for separate test data containers and access methods for each programming language, making it inefficient and resource-intensive to test applications written in different languages.

Innovation Solution

A programming language independent test data environment is implemented, where a single database with separate persistencies for real and test data allows access to either type of data based on the application's operating mode, eliminating the need for language-specific test data containers and access methods.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If separate test data containers and access methods are created for each programming language, then each language can be tested independently, but the device complexity and development time increase significantly

Engineering Contradiction:
Improvetesting independenceVSAvoidtest data container complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements a universal test data container that serves multiple programming languages through a single interface. The container uses a unified access method that works across different languages (e.g., Java, C#, ABAP) without requiring language-specific implementations. This allows the same test data infrastructure to support diverse programming languages, eliminating the need for separate containers for each language while maintaining testing independence.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Reliability

If separate test data containers are implemented for each programming language, then language-specific testing requirements are met, but the loss of time and resources increases

Engineering Contradiction:
Improvelanguage-specific testingVSAvoidtesting setup time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The universal test data container eliminates repetitive setup work by providing a single shared infrastructure that all programming languages can use. Instead of creating separate containers for each language, the system reuses the same container across all languages, significantly reducing the time and resources required for testing setup while still meeting language-specific testing requirements through language-agnostic access methods.

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Ease of operation

If programming language independent access is implemented, then ease of operation improves, but the difficulty of detecting and measuring language-specific nuances increases

Engineering Contradiction:
Improvedata access simplicityVSAvoidlanguage-specific behavior detection
Core Design Contradiction:
Ease of operationVSDifficulty of detecting and measuring

Solution Approach 1:

The patent introduces an intermediary layer in the form of a universal access method that mediates between the programming language and the test data container. This intermediary translates language-specific operations into a unified access interface, simplifying the operation for developers while maintaining the ability to detect and measure language-specific behaviors through the standardized interface. The intermediary abstracts away the complexity of language-specific nuances while preserving observability.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS11003668B2Programming language independent software testing environment
Publication Date: 2021.05.11 SAP SE
  • US11003668B2 patent drawing
  • US11003668B2 patent drawing
  • US11003668B2 patent drawing

AI summary

Provided are systems and methods for programming language independent application development via test data stored in a database. In one example, the method includes receiving a database command from an application, the database command including a location and an access request for data at the location, determining if the application is operating in a test mode, and accessing data from a database based on the database command, wherein the accessing data comprises accessing test data stored in a test data storage based on the location included in the database command if the application is operating in the test mode, and accessing real data stored in a real data storage based on the location included in the database command if the application is not operating in test mode.