Improving test case

[abhijeetSaroha]

No description provided.

[abhijeetSaroha]

I have created the initial PR for test cases, but it has some issue, test cases is not passing currently, anyone can help me in that how to improve this.

[felipepaes]

Hey @abhijeetSaroha I was thinking if instead of adding a mock test for avoiding the ci not selecting any tests. We could implement a test for the utils module by creating tests/test_utils.py for it.

Here is how it would look like

"""Tests for anamnesisai package utility module."""

import pytest

from typing import Type

from fhir.resources.resource import Resource

from anamnesisai.utils import get_resource_detail


class MockResource(Resource):  # type: ignore[misc]
    """Disclaimer: Any field name ends with ``__ext`` doesn't part of
    Resource StructureDefinition, instead used to enable Extensibility feature
    for FHIR Primitive Data Types.

    MOCK RESOURCE FOR TESTING PURPOSES ONLY. 
    This is a simulated DomainResource used to test resource handling functionality.
    It mimics the structure of a real FHIR resource but contains no actual implementation.
    """


@pytest.fixture
def resource() -> Type[Resource]:
    """Mock Resource fixture."""  # noqa: D202

    return MockResource


def test_get_resource_detail(resource: Type[Resource]) -> None:
    """Test get_resource_detail function."""
    expected = (
        "MOCK RESOURCE FOR TESTING PURPOSES ONLY. "
        "This is a simulated DomainResource used to test "
        "resource handling functionality. It mimics the "
        "structure of a real FHIR resource but contains no "
        "actual implementation."
    )
    assert get_resource_detail(resource) == expected

ps. I has to add # type: ignore[misc] otherwise mypy complains that we are subclassing from type Any

This should be enough to avoid the non tests selected error. You can try it locally by running makim tests.unit --params "-v tests/test_utils.py"

[felipepaes]

LGTM @abhijeetSaroha ! Did it run ok locally?

[felipepaes]

This would be quite expensive, running the extract_fhr_resources against all synthetic files would take a lot of time and api calls.

[felipepaes]

In the future we may need another fixture to get the api key from a dictionary where the key will be the backend literal and the value will be the API_KEY from .env, but right now I don't think it's necessary. We can do that once we implement ollama and/or other LLMs