Testing Coverage Report

[iledesma08]

Summary

This issue will be about the results obtained after unit-testing the project

[iledesma08]

[iledesma08]

Testing Coverage Report for src Directory

The testing coverage report for the src directory highlights the current status of unit tests across various components of the memory management system. The src directory contains critical files that implement memory allocation, deallocation, block management, and interaction with the operating system for memory operations.

Coverage Summary for src

From the LCOV report:

• Line Coverage: 34.5%
• Function Coverage: 47.8%

This coverage level indicates that essential functionality is well-tested, while other areas, particularly error handling and edge cases, are verified manually. This reflects a balanced approach, ensuring critical paths are validated through unit tests while system-dependent behaviors are validated through interactive testing.

Analysis of Code Coverage

The src directory includes multiple functionalities critical to the custom memory management system. Here’s a breakdown of the areas covered and uncovered:

1. Memory Allocation (my_malloc):

   • Basic allocation logic, including finding suitable blocks (find_block) and extending the heap, is well-covered.
   • Edge cases, such as aligning memory sizes and splitting blocks, have automated tests.
   • Error handling for allocation failures (e.g., mmap failures) is currently verified manually due to system dependencies.

2. Memory Deallocation (my_free):

   • Core functionality for freeing blocks and merging adjacent free blocks (fusion) is tested.
   • Scenarios involving freeing already-freed or invalid blocks are validated interactively to simulate real-world usage.

3. Zero Initialization (my_calloc):

   • Automated tests ensure memory is correctly zeroed upon allocation.
   • Handling of edge cases, such as zero-sized allocations, is partially automated but also manually validated.

4. Reallocation (my_realloc):

   • Automated tests cover reallocating to larger sizes and verifying data integrity after reallocation.
   • Reallocating to smaller sizes and complex scenarios (e.g., resizing in-place) are currently validated interactively.

5. Block Management (split_block and fusion):

   • Splitting blocks for allocations and merging blocks during deallocation are thoroughly tested.
   • Automated tests ensure proper updates to metadata (e.g., size, next, prev pointers) after these operations.

6. Address Validation (valid_addr):

   • Functions for verifying pointers are part of the heap are tested, ensuring robustness in normal usage scenarios.
   • Invalid or random pointers (e.g., 0x12345678) are tested interactively to simulate realistic misuse cases.

7. Heap Extension (extend_heap):

   • Core functionality for requesting additional memory from the operating system via mmap is tested.
   • Scenarios involving system-level failures are verified interactively due to their dependency on the operating environment.

Considerations and Limitations

Achieving complete unit test coverage across the src directory would require substantial additional testing infrastructure. Specifically:

• Many functions interact directly with the operating system (e.g., mmap, munmap), making them challenging to reproduce consistently in a unit test environment.
• Complex scenarios involving concurrent access to memory have not been tested.

To complement automated tests, extensive manual testing has been conducted by simulating various scenarios, including:

• Stress testing with large-scale memory allocations and deallocations.
• Simulating edge cases, such as freeing invalid pointers or reallocating under low-memory conditions.
• Validating system interactions, such as proper behavior when mmap or munmap calls fail.

Conclusion

While the overall line and function coverage for the src directory are moderate (34.5% and 47.8%, respectively), this level is appropriate for this phase of the project. Core functionality has been validated, and system-level behaviors have been extensively tested interactively. Further automated testing would require significant investment in infrastructure and may yield diminishing returns. This approach balances test coverage with efficiency, providing reasonable confidence in the allocator's robustness.