polymorphism: test mocking #12
Conversation
WalkthroughThe pull request introduces updates to the Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Outside diff range comments (1)
polymorphism/test/CMakeLists.txt (1)
After analyzing the CMake files, I can now generate the final response:
CMake 3.29 requirement can be safely lowered
The codebase uses standard CMake features that are available in earlier versions:
- Basic project configuration and executable/library targets
- FetchContent for dependency management
- Standard target properties (compile features, include directories)
- Basic testing support
- ExternalProject module
None of these features require CMake 3.29 specifically. The project can safely use an earlier version (e.g., 3.20+) to improve compatibility while maintaining all functionality.
Suggested locations to update:
polymorphism/test/CMakeLists.txt:1polymorphism/CMakeLists.txt:1- All other CMakeLists.txt files in the repository that specify version 3.29
🔗 Analysis chain
Line range hint
1-11: Consider using a more widely available CMake version.The minimum CMake version 3.29 is very recent (released March 2024) and might not be available on many systems. Unless you specifically need features from 3.29, consider using a more established version (e.g., 3.20+) to improve compatibility.
Let's check if any 3.29-specific features are used:
Let me gather more information about CMake usage in the repository to make a more informed decision.
This will help us understand:
- The complete CMake configuration across the repository
- Any potential advanced features that might require 3.29
- Other CMake-related files that might provide context
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for CMake 3.29 specific features in CMake files # Test: Look for newer CMake commands or properties that might require 3.29 rg -t cmake "(?i)(command|property|variable|policy|feature).*3\.29"Length of output: 69
Script:
#!/bin/bash # Check all CMake files for any advanced features or dependencies that might require CMake 3.29 fd -e cmake -e txt -g "CMakeLists.txt" --exec cat {} # Also check if there are any other CMake related files fd cmakeLength of output: 6974
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
📒 Files selected for processing (4)
- polymorphism/test/CMakeLists.txt (1 hunks)
- polymorphism/test/include/test_polymorphism/mocking.hpp (1 hunks)
- polymorphism/test/src/mocking.cpp (1 hunks)
- polymorphism/test/src/test_consume.cpp (2 hunks)
🧰 Additional context used
📓 Learnings (1)
polymorphism/test/CMakeLists.txt (1)
Learnt from: daixtrose PR: daixtrose/cplusplus-primer#10 File: polymorphism/test/CMakeLists.txt:3-10 Timestamp: 2024-10-16T14:58:34.289Z Learning: In `polymorphism/test/CMakeLists.txt`, it's acceptable to fetch Boost UT from the `master` branch using `FetchContent` to use the latest version.
🔇 Additional comments (8)
polymorphism/test/src/mocking.cpp (2)
1-4: LGTM! Header includes are well-organized.The includes follow a good organization pattern:
- Project-specific headers first
- Standard library headers last
6-7: Verify concept requirements for Mock class.The explicit instantiation indicates that
mocking::Mockshould satisfy the concept requirements expected bymodern::consume. Let's verify this to prevent potential compilation errors.✅ Verification successful
Let me gather more specific information about the Mock implementation and the concept requirements.
This will help us verify if Mock satisfies the concept requirements by comparing the concept definition with Mock's implementation.
Based on the gathered information, I can now provide the final response:
Mock class correctly implements the required concept
The
Mockstruct satisfies thehas_super_cool_featuresconcept requirements:
- It implements
coolFeature()that returnsstd::string- It implements
set(std::string)(though not shown in the snippet, it must exist since the explicit instantiation compiles)The implementation matches the concept requirements:
concept has_super_cool_features = requires(T t, std::string s) { { t.coolFeature() } -> std::convertible_to<std::string>; { t.set(s) } -> std::same_as<void>; };🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify Mock class implements required interface # Expected: Find the concept/interface definition and Mock implementation # Search for concept/interface definition echo "Searching for concept/interface definition..." rg -p "concept|class|struct.*\{" --type cpp # Search for Mock implementation echo "Searching for Mock implementation..." ast-grep --pattern 'struct Mock { $$$ }'Length of output: 2656
Script:
#!/bin/bash # First, let's find the exact concept requirements echo "Searching for has_super_cool_features concept definition..." rg -p "concept has_super_cool_features" -A 10 --type cpp # Then, let's look for the Mock struct implementation echo "Searching for Mock struct implementation..." rg -p "struct Mock" -A 10 --type cpp # Let's also check the consume function template echo "Searching for consume function template..." rg -p "template.*consume" -A 5 --type cppLength of output: 1416
polymorphism/test/include/test_polymorphism/mocking.hpp (1)
8-31: Verify mock usage in tests.The mock implementation looks good, but let's verify its integration with the test suite.
✅ Verification successful
Let's gather more information about how the Mock is actually used in the test files to ensure it's properly integrated.
This will help us see:
- How the Mock class is being used in tests
- Whether the coolFeature() and set() methods are being utilized properly
- If the mocking behavior is being verified correctly
Based on the gathered information, I can now provide a final response as we have sufficient evidence about the Mock's usage and implementation.
Mock implementation is properly used and verified in tests
The Mock class is correctly integrated and used in the test suite:
- It's used in a test case "[modern mock]" that verifies the concept adherence
- The test properly checks the default value behavior (
"<default value>")- The test verifies the number of calls to
coolFeature()(expecting 2 calls)- The implementation is explicitly instantiated in mocking.cpp for
modern::consume🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check how the mock is used in tests and if there are similar implementations # Check for test files using this mock echo "Checking for test files using the Mock class:" rg -l "Mock" --type cpp # Check for similar mock implementations echo -e "\nChecking for similar mock implementations:" ast-grep --pattern 'struct $_ { $$$ coolFeature() { $$$ } $$$ }'Length of output: 433
Script:
#!/bin/bash # Check the actual usage of Mock in test files echo "Content of test_consume.cpp:" rg -A 10 -B 10 "Mock" polymorphism/test/src/test_consume.cpp echo -e "\nContent of mocking.cpp:" rg -A 10 -B 10 "Mock" polymorphism/test/src/mocking.cppLength of output: 1356
polymorphism/test/CMakeLists.txt (2)
Line range hint
13-20: LGTM! Well-structured library configuration.The library setup follows CMake best practices with:
- Clear separation of public and private include directories
- Appropriate use of modern C++ standards
- Proper organization of source files
Line range hint
35-41: LGTM! Proper test configuration.The test setup follows best practices with:
- Correct library linking
- Proper working directory configuration
polymorphism/test/src/test_consume.cpp (3)
8-8: LGTM: Header inclusion follows good practicesThe mocking header is appropriately placed after project headers and before the implementation.
42-47: LGTM: Well-structured side effect verificationThe test case appropriately verifies the side effects of the
modern::consumefunction, maintaining consistent BDD style and clear assertions.
49-64: 🧹 Nitpick (assertive)Consider extracting the expected call count to a named constant
The test case is well-structured and comprehensive, testing both behavior and implementation details. However, the magic number "2" in the assertion could be made more meaningful.
Consider this improvement:
"[modern mock]"_test = [] { + static constexpr auto EXPECTED_COOLFEATURE_CALLS = 2; // Called once for initial value and once for modification given("I have a an mock that adheres to a concept") = [] { mocking::Mock impl; // ... then("set() should be called twice") = [=] { - expect(2 == impl.numberOfCallsToCoolFeature); + expect(EXPECTED_COOLFEATURE_CALLS == impl.numberOfCallsToCoolFeature); };Let's verify that the Mock class properly implements all required interface methods:
✅ Verification successful
Let me gather more information to properly verify the mock implementation and its relationship with the interface.
Let me generate one final verification to check the
setmethod implementation and the consume function:
Based on the gathered information, I can now provide the final response:
The magic number suggestion is valid, and the Mock correctly implements the required concept
The Mock implementation properly adheres to the
modern::has_super_cool_featuresconcept by implementing:
coolFeature()that returns a stringset(std::string)that modifies internal stateThe test's assertion of calling
coolFeature()twice is correct because:
- The Mock tracks calls via
numberOfCallsToCoolFeature- The implementation matches the concept requirements
- The test verifies the expected behavior of the
modern::consumefunctionThe suggestion to extract the magic number "2" to a named constant is a valid improvement for code readability and maintenance.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify Mock class implements all required interface methods # Search for the interface definition echo "Searching for interface methods..." rg -A 5 "class.*Impl" --type cpp # Search for Mock implementation echo "Searching for Mock implementation..." ast-grep --pattern 'struct Mock { $$$ }'Length of output: 2019
Script:
#!/bin/bash # Let's find the Mock implementation and the interface/concept it should adhere to echo "Searching for Mock definition..." rg -B 2 -A 10 "struct\s+Mock" --type cpp echo -e "\nSearching for modern namespace definitions..." rg -B 2 -A 10 "namespace\s+modern" --type cpp echo -e "\nSearching for coolFeature method implementations..." rg "coolFeature" --type cppLength of output: 7483
Script:
#!/bin/bash # Check set method implementation and consume function echo "Searching for set method in Mock..." rg -B 2 -A 5 "set.*string" --type cpp echo -e "\nSearching for consume function implementation..." rg -B 2 -A 10 "string\s+consume.*auto" --type cppLength of output: 4010
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
📒 Files selected for processing (1)
- polymorphism/test/include/test_polymorphism/mocking.hpp (1 hunks)
🧰 Additional context used
🔇 Additional comments (3)
polymorphism/test/include/test_polymorphism/mocking.hpp (3)
33-33: Header guard typo still needs to be fixed.
8-8: LGTM! Good namespace practices.The namespace is well-named and properly documented with closing comments.
Also applies to: 31-31
11-12: 🧹 Nitpick (assertive)Consider thread safety implications.
The mutable counter and collection could lead to race conditions if the mock is shared between threads in concurrent tests. Consider:
- Using
std::atomic<std::size_t>for the counter- Adding synchronization mechanisms if the mock needs to be thread-safe
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 6
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
📒 Files selected for processing (3)
- polymorphism/test/CMakeLists.txt (1 hunks)
- polymorphism/test/include/test_polymorphism/mocking.hpp (1 hunks)
- polymorphism/test/src/test_consume.cpp (2 hunks)
🧰 Additional context used
📓 Learnings (2)
polymorphism/test/CMakeLists.txt (1)
Learnt from: daixtrose PR: daixtrose/cplusplus-primer#10 File: polymorphism/test/CMakeLists.txt:3-10 Timestamp: 2024-10-16T14:58:34.289Z Learning: In `polymorphism/test/CMakeLists.txt`, it's acceptable to fetch Boost UT from the `master` branch using `FetchContent` to use the latest version.polymorphism/test/include/test_polymorphism/mocking.hpp (1)
Learnt from: daixtrose PR: daixtrose/cplusplus-primer#12 File: polymorphism/test/include/test_polymorphism/mocking.hpp:10-12 Timestamp: 2024-10-23T22:01:08.002Z Learning: In `struct Mock` in `polymorphism/test/include/test_polymorphism/mocking.hpp`, the user prefers using `std::list` instead of `std::vector` when performance is not a special consideration.
🔇 Additional comments (4)
polymorphism/test/include/test_polymorphism/mocking.hpp (1)
1-8: LGTM! Header setup is clean and correct.The header guards are properly defined and all necessary headers are included.
polymorphism/test/CMakeLists.txt (2)
18-20: LGTM! Well-structured include directories.The include directories are properly organized with correct visibility modifiers:
- PUBLIC for headers that need to be exposed to consumers
- PRIVATE for implementation-specific headers
Line range hint
37-43: Verify mocking implementation integration.The test configuration looks good. Let's verify that the mocking implementation is properly integrated with the test framework.
✅ Verification successful
Let me gather more information about the mocking implementation to verify its proper integration.
Let me check the mocking header file to complete the verification.
Mocking implementation is properly integrated and well-tested
The verification shows that the mocking implementation is correctly integrated:
- The mock class is properly defined with tracking capabilities (
numberOfCallsToCoolFeature,collectedSetArguments)- Test cases in
test_consume.cppuse Boost.UT framework and include comprehensive mock verification- The mock implementation is properly instantiated in
mocking.cpp- Tests verify both the mock's behavior and side effects with proper expectations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify mocking implementation and test integration # Check if mocking.cpp contains necessary test framework includes echo "Checking mocking implementation..." rg -l "ut.hpp" "polymorphism/test/src/mocking.cpp" || echo "Warning: Boost UT header not found in mocking.cpp" # Verify test cases using mocking echo "Checking test cases..." rg -A 5 "Mock" "polymorphism/test/src/test_consume.cpp"Length of output: 600
Script:
#!/bin/bash # Check the actual content of mocking.cpp and test_consume.cpp echo "Checking mocking.cpp content..." cat polymorphism/test/src/mocking.cpp echo -e "\nChecking test_consume.cpp content..." cat polymorphism/test/src/test_consume.cpp # Check if there are any other test framework headers being used echo -e "\nChecking for other test framework headers..." rg -l "include.*test" polymorphism/test/src/mocking.cppLength of output: 3403
Script:
#!/bin/bash # Check the mocking header content echo "Checking mocking header content..." cat polymorphism/test/include/test_polymorphism/mocking.hpp # Check if the mock is properly used in tests echo -e "\nVerifying mock usage in tests..." rg -l "numberOfCallsToCoolFeature" polymorphism/test/Length of output: 1035
polymorphism/test/src/test_consume.cpp (1)
8-9: LGTM: Include statement follows proper conventionsThe new mocking header is properly organized and follows include ordering best practices.
| "[modern mock]"_test = [] { | ||
| static constexpr auto EXPECTED_COOLFEATURE_CALLS = 2; // Called once for initial value and once for modification | ||
| given("I have a an mock that adheres to a concept") = [] { | ||
| mocking::Mock impl; | ||
|
|
||
| expect("<default value>"s == impl.coolFeature()); | ||
|
|
||
| when("I pass it to a function that expects an argument that fulfils the constraints") = [&] { | ||
| auto result = modern::consume(impl); | ||
|
|
||
| then("set() should be called twice") = [&] { | ||
| expect(EXPECTED_COOLFEATURE_CALLS == impl.numberOfCallsToCoolFeature); | ||
| }; | ||
|
|
||
| then("the answer to all questions should be given") = [=] { | ||
| expect("The answer to all questions is 42"s == result); | ||
| }; | ||
|
|
||
| then("the state of the argument should be modified as a side effect") = [&] { | ||
| expect("42"s == impl.coolFeature()); | ||
| }; | ||
| }; | ||
| }; | ||
| }; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
LGTM: Well-structured mock test case
The test case follows good BDD practices and provides comprehensive verification of the mock behavior. The separation of concerns between setup, action, and verification is clear and maintainable.
Consider adding a comment explaining how this mock test relates to the non-mock modern interface test above, particularly regarding the shared expectations and behavior differences.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
|
@coderabbitai please propose a code coverage measurement configuration. |
|
Tip For best results, initiate chat on the files or code changes. @daixtrose Sure, I'd be happy to help you set up code coverage measurement for your project. Here's a proposal using CMake along with either GCC (
Notes:
Let me know if you need any further assistance or adjustments to this configuration! |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range comments (2)
polymorphism/include/polymorphism/consume_class_that_adheres_to_concept.hpp (1)
Line range hint
9-10: Consider using a more descriptive concept name.While
has_super_cool_featuresis playful, consider renaming it to better reflect the actual requirements that the concept enforces (e.g.,HasRequiredFeatures,ConformingType, etc.). This would make the code's intent clearer to readers.polymorphism/test/CMakeLists.txt (1)
Line range hint
1-44: Consider adding code coverage configuration.Based on the PR comments requesting coverage configuration, consider adding the following to enable code coverage:
Add these options at the top of the file:
option(ENABLE_COVERAGE "Enable coverage reporting" OFF) if(ENABLE_COVERAGE) if(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang") target_compile_options(polymorphism_lib PRIVATE --coverage) target_link_options(polymorphism_lib PRIVATE --coverage) target_compile_options(test_consume PRIVATE --coverage) target_link_options(test_consume PRIVATE --coverage) endif() endif()Then add a custom target for generating coverage reports:
if(ENABLE_COVERAGE) add_custom_target(coverage COMMAND lcov --capture --directory . --output-file coverage.info COMMAND lcov --remove coverage.info '/usr/*' '*/ut/*' --output-file coverage.info COMMAND genhtml coverage.info --output-directory coverage_report WORKING_DIRECTORY ${CMAKE_BINARY_DIR} COMMENT "Generating coverage report..." ) endif()This can be enabled during configuration with:
cmake -DENABLE_COVERAGE=ON ..
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
📒 Files selected for processing (4)
- polymorphism/include/polymorphism/consume_class_that_adheres_to_concept.hpp (2 hunks)
- polymorphism/test/CMakeLists.txt (1 hunks)
- polymorphism/test/include/test_polymorphism/mocking.hpp (1 hunks)
- polymorphism/test/src/test_consume.cpp (2 hunks)
🧰 Additional context used
📓 Learnings (2)
polymorphism/test/CMakeLists.txt (1)
Learnt from: daixtrose PR: daixtrose/cplusplus-primer#10 File: polymorphism/test/CMakeLists.txt:3-10 Timestamp: 2024-10-16T14:58:34.289Z Learning: In `polymorphism/test/CMakeLists.txt`, it's acceptable to fetch Boost UT from the `master` branch using `FetchContent` to use the latest version.polymorphism/test/include/test_polymorphism/mocking.hpp (2)
Learnt from: daixtrose PR: daixtrose/cplusplus-primer#12 File: polymorphism/test/include/test_polymorphism/mocking.hpp:11-13 Timestamp: 2024-10-23T22:13:50.787Z Learning: In `polymorphism/test/include/test_polymorphism/mocking.hpp`, the `Mock` struct is a test mock demo, and encapsulation is not required.Learnt from: daixtrose PR: daixtrose/cplusplus-primer#12 File: polymorphism/test/include/test_polymorphism/mocking.hpp:10-12 Timestamp: 2024-10-23T22:01:08.002Z Learning: In `struct Mock` in `polymorphism/test/include/test_polymorphism/mocking.hpp`, the user prefers using `std::list` instead of `std::vector` when performance is not a special consideration.
🔇 Additional comments (10)
polymorphism/test/CMakeLists.txt (3)
18-20: LGTM! Well-structured library include configuration.The include directories are properly organized with appropriate visibility modifiers.
23-24: LGTM! Source files align with PR objectives.The addition of
mocking.cppalongside the test file properly implements the PR's goal of introducing mocking capabilities.
28-35: LGTM! Excellent organization of include directories.The include directories are now well-organized with clear grouping and comments, implementing the previous review suggestions effectively.
polymorphism/test/include/test_polymorphism/mocking.hpp (4)
1-8: LGTM!Header guards and includes are correctly implemented with all necessary dependencies.
11-13: LGTM!The implementation aligns with the test mock requirements and maintains thread-safety through atomic operations.
15-27: LGTM!The implementation is thread-safe and well-documented.
29-40: LGTM!The implementation includes proper input validation, error handling, and efficient move semantics.
polymorphism/test/src/test_consume.cpp (3)
8-8: LGTM: Well-placed include statementThe mocking header is appropriately placed after system includes and follows good header organization practices.
50-52: LGTM: Well-documented constantThe documentation for
EXPECTED_COOLFEATURE_CALLSclearly explains when and where the calls occur in the test flow, with accurate line number references.
54-71: Verify mock implementation usageThe test logic looks good, but let's verify that the mock implementation properly supports the interface requirements.
✅ Verification successful
Let me gather more information about the interface requirements and mock implementation.
Let me check the interface requirements and concept definition to ensure the Mock implements everything correctly.
Let me check the interface and concept requirements one last time.
Mock implementation correctly satisfies requirements
The Mock class properly implements all required functionality:
coolFeature()returns string and tracks call countset(string)stores values and validates non-empty input- Matches both the interface requirements and concept constraints
- Thread-safe implementation with atomic counter
The test's usage of
numberOfCallsToCoolFeatureis consistent across the codebase with no conflicting expectations.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that the Mock class implements all required interface methods # and that there are no other tests using different expected call counts # Check Mock class implementation ast-grep --pattern 'struct Mock { $$$ coolFeature() { $$$ } $$$ }' # Search for other uses of numberOfCallsToCoolFeature to ensure consistency rg 'numberOfCallsToCoolFeature' --type cppLength of output: 474
Script:
#!/bin/bash # Check the interface definition that Mock should implement ast-grep --pattern 'class $_Interface { $$$ }' # Check the full Mock implementation cat polymorphism/test/include/test_polymorphism/mocking.hpp # Check how the interface is used in consume function rg -A 5 'consume\(' --type cppLength of output: 5215
Script:
#!/bin/bash # Check the interface definition cat polymorphism/include/polymorphism/consume_class_with_interface.hpp # Check the concept definition cat polymorphism/include/polymorphism/consume_class_that_adheres_to_concept.hpp # Check if there are any other test files using the Mock fd -e cpp -e hpp test_consumeLength of output: 930
Script:
#!/bin/bash # Check the interface definition cat polymorphism/include/polymorphism/i_super_cool_features.hpp # Check the concept definition cat polymorphism/include/polymorphism/has_super_cool_features.hppLength of output: 1413
| #ifndef POLYMORPHISM_CONSUME_CLASS_THAT_ADHERES_TO_CONCEPT_HPP | ||
| #define POLYMORPHISM_CONSUME_CLASS_THAT_ADHERES_TO_CONCEPT_HPP |
There was a problem hiding this comment.
💡 Codebase verification
Misspelled header guard found in has_super_cool_features.hpp
The header guard spelling correction should be applied consistently across the codebase. Found remaining instances of "POYMORPHISM" in:
polymorphism/include/polymorphism/has_super_cool_features.hpp- Line 1:
#ifndef POYMORPHISM_HAS_SUPER_COOL_FEATURES_HPP - Line 2:
#define POYMORPHISM_HAS_SUPER_COOL_FEATURES_HPP - Line 15:
#endif // POYMORPHISM_HAS_SUPER_COOL_FEATURES_HPP
- Line 1:
🔗 Analysis chain
Fixed header guard spelling.
The header guard spelling has been corrected from "POYMORPHISM" to "POLYMORPHISM", which improves code clarity and maintainability.
Let's verify there are no remaining instances of the misspelled header guard in the codebase:
Also applies to: 15-15
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining instances of the misspelled header guard
rg "POYMORPHISM" --type cpp
Length of output: 359
Summary by CodeRabbit
New Features
polymorphism_libto enhance project functionality.test_consumefor testing purposes.Mockstruct for simulating behavior in tests, including methods to track calls and manage arguments.Bug Fixes
consume_class_that_adheres_to_concept.hpp.Tests