test: Improve Tests for `nvd_api.py` file

[JigyasuRajput]

Description

Several functions in cve_bin_tool/nvd_api.py lack proper test coverage.
~~ report

Affected Functions

• nvd_count_metadata (async, staticmethod)
• convert_date_to_nvd_date_api2 (staticmethod)
• get_reject_count_api2 (staticmethod)
• get_nvd_params (async)
• validate_nvd_api (async)
• load_nvd_request (async)
• get (async)

Steps to Reproduce

Currently, there are no proper tests ensuring the correctness of these functions.

Expected Behavior

• Unit tests should be written for each function.
• Mock API calls where necessary to simulate different scenarios.

Suggested Approach

• Use pytest and unittest.mock for mocking API responses.
• For async functions, use pytest-asyncio.
• Ensure coverage for both success and failure cases.

[terriko]

You're not wrong about these, but I just want to note that we need to be extra careful about not abusing the NVD api here, since it's a shared resource under a lot of very big load. Mocked tests are fine, but we should not have any more network tests to any NVD code unless there's a clear benefit.

Note that while we don't have these as part of the coverage numbers, some of these functions are running daily as part of our cache updates, so they're not really going totally untested, they're just not counted by codecov. There's maybe a project to figure out what parts are running daily so we don't have to add additional tests on them, but I'd venture that this is pretty low priority for us. I'd much rather people work on other issues over this one.

[Saksham-Sirohi]

Hi @terriko ,
I’m preparing a PR to improve test coverage for nvd_api.py by adding mocked unit tests for key functions (nvd_count_metadata, convert_date_to_nvd_date_api2, get_reject_count_api2, etc.). The changes:

🛠️ Add new tests using AsyncMock/FakeResponse to avoid real NVD API calls.
✅ Validate edge cases (invalid API keys, rejected CVEs, pagination).
🔄 Preserve existing integration tests (skipped by default to avoid API strain).
🚫 Zero breaking changes—existing logic remains untouched.

This aligns with project guidelines to minimize external API usage while ensuring critical paths are tested. However, if I have missed something, Feedback is welcome!

[JigyasuRajput]

@saisharan0103
Sounds right. Just a heads up: NVD is a pretty flaky API, it goes down or rate-limits fairly often, so a failing test there can mean the API is having a bad day rather than the code being wrong. Please make sure everything is properly mocked so the tests are deterministic and don't add any new network calls to NVD. The static helpers (convert_date_to_nvd_date_api2, get_reject_count_api2) are pure functions so those are easy wins with plain unit tests.