Direct Mapping Analysis #
Direct Mapping Analysis is the most straightforward and fundamental strategy in FASTEST for identifying test cases that need to be executed when code changes occur. This strategy establishes direct relationships between modified code components and their corresponding test cases.
What is Direct Mapping Analysis? #
Direct Mapping Analysis works by creating explicit connections between source code functions, classes, or modules and the test cases that verify their behavior. When code changes are detected, the system immediately identifies which tests are directly related to those changes, ensuring that the most relevant tests are prioritized for execution.
Core Principle #
The strategy operates on the principle that every code change should trigger the execution of tests that directly verify the modified functionality. This creates a one-to-one or one-to-many relationship between code components and their test cases.
When to Use Direct Mapping #
Ideal Scenarios #
- Bug Fixes: When fixing specific issues in well-defined functions
- Feature Updates: Modifying existing functionality with established test coverage
- Refactoring: Restructuring code while maintaining the same functionality
- Small Changes: Minor modifications to individual functions or methods
Best Results With #
- Well-Structured Tests: Clear test organization with descriptive naming
- Good Coverage: Existing test coverage for the modified components
- Modular Code: Code organized into discrete, testable units
Benefits and Advantages #
Efficiency #
- Fast Execution: Quickly identifies relevant tests without complex analysis
- Minimal Overhead: Low computational cost for test selection
- Immediate Results: Provides instant feedback on which tests to run
Accuracy #
- High Precision: Direct relationships ensure relevant test selection
- Low False Positives: Rarely selects unnecessary tests
- Predictable Results: Consistent and reliable test identification
Simplicity #
- Easy to Understand: Clear logic that developers can easily follow
- Transparent Process: Shows exactly why each test was selected
- Debugging Friendly: Simple to troubleshoot when issues arise
Example Scenarios #
Scenario 1: Function Modification #
// Modified function int calculateSum(int a, int b) { return a + b + 1; // Bug fix: added missing increment }
Selected Tests:
testCalculateSum()
testCalculateSumEdgeCases()
- Any integration tests using
calculateSum()
Scenario 2: Class Method Update #
// Modified method in StringUtils class std::string StringUtils::trim(const std::string& str) { // Updated trimming logic }
Selected Tests:
StringUtilsTest::testTrim()
StringUtilsTest::testTrimEdgeCases()
- Tests in other suites that use
StringUtils::trim()
This foundational strategy ensures that the most obvious and critical tests are always included in your execution plan, providing a solid baseline for intelligent test selection.