Software Unit Dependency Graph for Code Change Testing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In software maintenance and development, testing complex object-oriented code changes is time-consuming and resource-intensive due to the intricate interrelations between code and objects, making comprehensive full testing impractical for all but trivial programs.

Innovation Solution

A system comprising a software unit dependency graph generator, a dependent software unit collector, a dependency analyzer, a code change tracker, and an impact assessment engine determines the relevance of code changes by analyzing dependency graphs and key impact factors, optimizing testing by selecting the most critical tests to perform based on code complexity and evolution.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If comprehensive full testing is performed to ensure all functionality meets specifications, then test quality and reliability are improved, but time consumption and computational resources increase significantly

Engineering Contradiction:
Improvetest qualityVSAvoidtime consumption
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent segments the codebase into software units and creates a dependency graph to identify and test only the relevant segments affected by changes. This segmentation allows comprehensive testing of critical paths without requiring exhaustive testing of the entire system, thus maintaining high test quality while reducing time consumption.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies partial action by performing testing only on the necessary subset of code affected by changes rather than the entire codebase. The dependency analysis identifies the minimal set of test cases needed to verify quality, avoiding excessive testing of unrelated code sections.

Inventive Principle:
Principle #16Partial or excessive action

2Reliability

If comprehensive full testing is performed to cover all code interrelations, then test coverage is improved, but computational resources and calculation time increase beyond practical limits

Engineering Contradiction:
Improvetest coverageVSAvoidcomputational efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The codebase is divided into discrete software units with documented dependencies. The dependency graph segments the testing workload into manageable units, allowing the system to focus computational resources only on testing the specific units and their dependencies that are affected by changes, rather than testing everything.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent performs preliminary dependency analysis before testing to pre-identify which code units and test cases are relevant. This preliminary action of mapping dependencies allows the system to efficiently select only the necessary test cases, avoiding wasteful computation on unrelated code paths.

Inventive Principle:
Principle #10Preliminary action

3Measurement precision

If detailed dependency analysis is performed to identify relevant test cases, then test precision is improved, but device complexity increases

Engineering Contradiction:
Improvetest precisionVSAvoidsystem complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The patent introduces a dependency graph as an intermediary structure that systematically represents code relationships. This intermediary automates the complex task of tracking dependencies between software units, making the precision achievable through structured analysis rather than ad-hoc complex reasoning.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent replaces manual, complex dependency tracking with an automated computational system that builds and queries dependency graphs. This substitution of mechanical analysis with algorithmic processing achieves high precision in identifying relevant tests while managing system complexity through automation.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Data Source

PatentUS8584100B2Bridging code changes and testing
Publication Date: 2013.11.12 SAP SE
  • US8584100B2 patent drawing
  • US8584100B2 patent drawing
  • US8584100B2 patent drawing

AI summary

Method and system for testing software code comprising determining code elements in software code, determining changed code elements in the software code, determining dependencies between code elements, determine dependency changes between code elements based on the determined changed code elements, determining an impact factor for the respective changed code elements based on the determined dependency changes, determine a test relevancy ranking for code tests based on the determined impact factor, selecting tests for the software code based on said test relevancy ranking, and performing the selected tests on the software code.