test: Add Unit Tests for consumption.py

[brf153]

This PR introduces unit tests for the consumption.py in the kai.service.solution_handling.consumption module. The tests cover the following functionalities:

• solution_consumer_diff_only
• solution_consumer_before_and_after
• solution_consumer_llm_summary
• solution_consumer_factory

[JonahSussman]

Thanks for your contribution! I'm a big fan of tests, but it appears that these tests are only verifying the "happy path". I'd love to see something a bit more thorough.

[brf153]

@JonahSussman thank you for taking a look at the changes. I've added tests to cover the edge cases. Below are the specific edge cases I've addressed:

1. Handling Empty Strings in Templates

Added a test to check the behavior when the template itself might render an empty string. This ensures that the system handles cases where the rendered output is an empty string correctly.

2. Partial Success in Multiple Kinds

Added a test for scenarios where multiple kinds are passed to the solution_consumer_factory, and one of them partially succeeds while others fail. This is important for testing the fallback functionality and ensuring that any failures are handled gracefully.

3. Empty Solution Handling

Added a test to ensure that the solution_consumer_diff_only function handles an empty file_diff gracefully, returning a non-empty string to avoid breaking the application.

4. Large Solution Data Handling

Added a test to verify that the solution_consumer_before_and_after function can handle large strings in the solution object without issues.

5. Template Not Found

Added a test to confirm that a TemplateNotFound exception is raised when a template is missing, ensuring that missing templates are handled correctly.

6. Resource Cleanup

Added a test to ensure proper resource cleanup by verifying that the template's render method is called exactly once.

7. Mixed Valid and Invalid Kinds

Added a test to check that the solution_consumer_factory function raises a ValueError when provided with a mix of valid and invalid kinds, ensuring that invalid kinds are properly flagged.

These edge cases should enhance the robustness of the solution consumer functionality. Let me know if any additional cases should be considered.