Adapted skills:check and skills:install and added reusable tests

[jana-selva]

Fixes #963

Checklist

Note: If any of the items in the checklist are not relevant to your PR, just check the box.

For any Pull Request

Is the following correct:

• the title of the Pull Request?
• the title of the corresponding issue?
• there are no other open Pull Requests for the same update/change?
• that the issue which this Pull Request fixes ("Fixes...") is mentioned?

When Changes Were Made

Did you:

• update the changelog?
• update the cookiecutter-template?
• update the implementation?
• check coverage and add tests: unit tests and, if relevant, integration tests?
• update the User Guide & other documentation?
• resolve any failing CI criteria (incl. Sonar quality gate)?

When Preparing a Release

Have you:

• thought about version number (major, minor, patch)?
• checked Exasol packages for updates and resolved open vulnerabilities, if easily possible?

[sonarqubecloud]

❌ The last analysis has failed.

See analysis details on SonarQube Cloud

[ArBridgeman]

These kinds of tests are require lots of maintenance, if the code is changed.

[ArBridgeman]

Quality Gate failed

Failed conditions 75.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

Ah, please add a test for project:check

[jana-selva]

Quality Gate failed

Failed conditions 75.0% Coverage on New Code (required ≥ 80%)
See analysis details on SonarQube Cloud

Ah, please add a test for project:check

Fixed

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ArBridgeman]

PackagedSkillEvalCases.model_validate() already enforces:

• version == 1
• non-empty skill, id, category, and prompt
• non-empty cases
• non-empty must_include / must_not_include
• non-blank string values
• required nested fields
• forbidden extra fields

So these tests add little value, so I'd remove them:

• test_cases_have_required_fields
• test_cases_have_response_constraints
• eval_cases.cases in test_has_expected_metadata
• eval_cases.version == 1 in test_has_expected_metadata

Instead, I'd recommend that you test that the Pydantic model behaves as it should, meaning that you verify that it rejects values that don't behave well.

@pytest.mark.parametrize(
    "invalid_case",
    [
        {"version": 2, "skill": "skill", "cases": []},
        {"version": 1, "skill": "", "cases": []},
        {"version": 1, "skill": "skill", "cases": []},
        {
            "version": 1,
            "skill": "skill",
            "cases": [{"id": "x", "category": "x", "prompt": "x"}],
        },
    ],
)
def test_rejects_invalid_eval_cases(invalid_case):
    with pytest.raises(ValidationError):
        PackagedSkillEvalCases.model_validate(invalid_case)

[ArBridgeman]

Related to the previous comment, I'd split the fixture from the validation, so that the validation is in a test.

@pytest.mark.parametrize("skill_name", _skills_with_eval_cases())
def test_packaged_skill_eval_cases_are_valid(skill_name):
    PackagedSkillEvalCases.model_validate(_load_eval_cases(skill_name))