Dynamic Mock Output Store for Parallel Software Testing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In complex software systems, changes to one module often require extensive development and testing of downstream modules, making it difficult to generate desired output values, and existing methods like static mock responses are cumbersome and costly in terms of development time and computing power.
Innovation Solution
Implementing a mock-enabled software module that accesses a mock output store, allowing for dynamic generation of mock output values based on special input, which can be triggered to produce either normal or mock outputs, enabling flexible and parallel testing scenarios without modifying the software modules themselves.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If static mock response data is hard-coded into software modules, then downstream modules can be tested with predefined output values, but changing the mock output data requires changing and recompiling the software modules, which increases development time and computing costs
Solution Approach 1:
The patent creates a separate mock output store that contains copies of output data, allowing downstream modules to be tested with mock data without modifying the original upstream modules. This copying approach enables independent testing while preserving the original module integrity, eliminating the need for recompilation when test data needs to change.
Solution Approach 2:
The patent introduces a mock output store as an intermediary component between upstream and downstream modules. This mediator holds mock output data that can be dynamically configured and retrieved, allowing downstream modules to consume mock data without direct modification of upstream modules, thus avoiding recompilation requirements.
2Reliability
If trial-and-error testing is performed to determine input values that produce desired output values, then the changed module can generate needed output for downstream module testing, but the process becomes very time-consuming
Solution Approach 1:
The patent pre-computes and stores mapping data that directly associates input values with output values in the mock output store. This preliminary action eliminates the need for time-consuming trial-and-error testing during actual testing, as the desired output values can be directly retrieved using the pre-established mappings.
Solution Approach 2:
The patent implements a mapping mechanism that provides direct feedback between input values and output values. Instead of requiring iterative trial-and-error testing, the system uses pre-established mappings to immediately determine which input values will produce the desired output values, significantly reducing testing time.
3Productivity
If multiple different test scenarios need to be run simultaneously, then comprehensive testing can be performed, but hard-coded static mock responses restrict the ability to run multiple tests at once and coordinate different test groups
Solution Approach 1:
The patent transforms the static, hard-coded mock response system into a dynamic one where the mock output store can be programmatically configured and modified at runtime. This dynamic approach allows multiple test scenarios to be activated simultaneously by simply changing the configuration data, without requiring module recompilation, thus enabling parallel testing and flexible coordination of different test groups.
Solution Approach 2:
The patent creates a universal mock output store that can serve multiple test scenarios and different test groups simultaneously. This multi-functional store can hold various sets of mock output data and can be configured to support different testing needs, allowing comprehensive parallel testing without the limitations of hard-coded static responses.
4Ease of manufacture
If control of changing test scenarios is taken out of testing professionals' hands by requiring software module changes, then mock output data can be modified, but testing professionals lose control and additional development overhead is created
Solution Approach 1:
The patent segments the testing control function from the software module code by creating a separate mock output store. This segmentation allows testing professionals to control and modify test scenarios through data configuration rather than code changes, maintaining their operational control while enabling easy mock data modification.
Solution Approach 2:
The patent introduces the mock output store as an intermediary layer between testing professionals and the software modules. This mediator allows testing professionals to control test scenarios by configuring data in the store without needing to modify or recompile software modules, thus preserving their control while simplifying the modification process.
Data Source
AI summary
Embodiments allow a mock-enabled software module to access a store of mock output data. Sets of mock output values (“SMOVs”), stored within the mock output store, are mapped to one or more key input values. When input sent to a mock-enabled software module includes one or more key input values that map to a given SMOV, the SMOV is included in a mock response from a target module of the given SMOV. When a set of input values, sent to a mock-enabled software module, does not include key input values that map to a SMOV, the mock-enabled module produces output without triggering any mock response. The mock output store may contain one or more replacement templates that are used to replace one or more mock output values, in a mock response, with one or more corresponding input values from the set of input values received by the triggering module.