Modular Test Framework Architecture for Web Services

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Traditional test frameworks are often monolithic, leading to code duplication and inflexibility, requiring significant refactoring when product features or APIs change, and do not allow for efficient code sharing among teams.

Innovation Solution

A modular test framework architecture that layers standalone sub-framework packages, allowing teams to plug in at various levels of abstraction, with multiple levels of abstraction in tests to isolate changes to lower layers, reducing the need for extensive refactoring and enabling code sharing across different teams and domains.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a monolithic test framework is used, then it provides complete functionality, but it causes code duplication and reduces flexibility

Engineering Contradiction:

ImproveflexibilityVSAvoidmonolithic structure

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The test framework is divided into multiple independent layers including base framework layer, domain-specific layer, and application-specific layer. Each layer can be developed, maintained, and reused independently, eliminating code duplication while providing complete functionality through composition of layers.

Inventive Principle:

Principle #1Segmentation

2Productivity

If a large complex framework is used to get 80% functionality, then it provides sufficient coverage, but it requires forcing fit for the remaining 20% functionality

Engineering Contradiction:

Improvefunctionality coverageVSAvoidease of use

Core Design Contradiction:

ProductivityVSEase of operation

Solution Approach 1:

The framework is segmented into reusable layers that can be selectively composed. Teams can start with base framework for 80% coverage and add only the specific domain or application layers needed for the remaining 20%, avoiding forcing fit and maintaining ease of use.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The base framework layer provides universal functionality that can serve multiple domains and applications. Domain-specific and application-specific layers extend this universal base to handle specialized requirements, allowing the same core framework to serve diverse testing needs.

Inventive Principle:

Principle #6Universality (Multi-functionality)

3Productivity

If test frameworks are built using assumptions about implementation details, then they provide specific functionality, but they require heavy refactoring when product changes occur

Engineering Contradiction:

Improvespecific functionalityVSAvoidadaptability to change

Core Design Contradiction:

ProductivityVSAdaptability or versatility

Solution Approach 1:

Implementation-specific assumptions are isolated to the lowest layers of the framework hierarchy. When product implementation details change, only the affected lower layers need modification, while higher layers remain stable and require no refactoring.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The framework introduces a vertical dimension of abstraction with multiple layers. This allows specific functionality to be implemented at appropriate levels while protecting higher levels from implementation changes, enabling adaptability without sacrificing productivity.

Inventive Principle:

Principle #17Another dimension (Dimensionality change)

4Ease of operation

If independent teams build custom test frameworks, then they meet specific team needs, but it leads to lack of code sharing

Engineering Contradiction:

Improveteam-specific customizationVSAvoidcode sharing

Core Design Contradiction:

Ease of operationVSQuantity of substance

Solution Approach 1:

The framework is segmented into shared base layers and customizable domain/application layers. Teams can share the standardized base framework code while customizing upper layers for team-specific needs, maximizing code sharing while maintaining customization capability.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The base framework layer provides universal functionality that serves all teams. Domain-specific layers enable multiple teams to share specialized functionality for common domains, reducing duplicate code while still allowing team-specific customization through application-specific layers.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS8904353B1Highly reusable test frameworks and tests for web services

Publication Date: 2014.12.02 AMAZON TECH INC

AI summary

Systems and methods for incrementally building tests and test frameworks may enable cost reduction and/or code sharing between teams testing various products (or features thereof) in different domains or of different product types. Test frameworks may be layered into standalone sub-framework packages that build on each other and whose object classes inherit object classes of lower layers. Sub-framework packages may provide generic utilities, domain-specific testing operations, application-specific testing operations, or operations for specific application types (e.g., web services). Test clients may plug into test frameworks at any layer to exercise features of a product under test. Tests may be built from components at multiple levels of abstraction, and may include test operations, test steps that include multiple test operations, and tests that include multiple test steps. Implementation details of products to be tested may only be visible to, and/or exercised by, the lowest-level elements of the tests (e.g., test operations).