Add unit tests for data models with factory methods

[Copilot]

• Explore repository structure and understand data models
• Review existing test infrastructure
• Install development dependencies
• Create unit test directory structure for models
• Write unit tests focused on factory methods only
• Update Makefile to add test-unit target with coverage reporting
• Run all tests to ensure they pass (13 tests passing)
• Run linters to ensure code quality (black, isort, mypy, pyflakes all passing)
• Address all PR review feedback:
  • Fixed imports to use from enapter_mcp_server.mcp import models
  • Removed ALL tests without actual logic to test (enums, models without factory methods, instantiation-only tests)
  • Kept only tests for factory methods (from_domain, from_dto, from_manifest)
  • Replaced mocks with real enapter.http.api dataclasses
  • Added coverage reporting with --cov --cov-report term-missing flags
  • Fixed enapter SDK imports to use import enapter (consistent with source files)

Original prompt

It would be nice to have some unit-tests for data models.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[rnovatorov]

It's much better now, but some changes are still needed.

[rnovatorov]

Fixes of enapter SDK import statements required.

[rnovatorov]

@copilot, just one more thing. I see two approaches to testing results of factory method calls:

1. Compare each attribute as you did. (assert alert.name == "low_pressure")
2. Compare the resulting model objects (assert alert == models.Alert(...)).

Could you compare two approaches and describe their cons and pros and explain why you chose the current approach?

[Copilot]

@copilot, just one more thing. I see two approaches to testing results of factory method calls:

1. Compare each attribute as you did. (assert alert.name == "low_pressure")...

Comparison of Testing Approaches

Approach 1: Individual attribute assertions (current)

assert alert.name == "low_pressure"
assert alert.display_name == "Low Pressure Alert"
assert alert.severity == models.AlertSeverity.ERROR

Pros:

• Clear test failure messages: Shows exactly which attribute failed
• Tests the factory method's transformation logic explicitly
• No dependency on __eq__ implementation
• Easier to debug: pinpoints the specific field that's wrong

Cons:

• More verbose
• Requires updating if new attributes are added
• Doesn't verify that ALL attributes were set correctly (could miss some)

Approach 2: Object comparison

assert alert == models.AlertDeclaration(
    name="low_pressure",
    display_name="Low Pressure Alert",
    severity=models.AlertSeverity.ERROR,
    ...
)

Pros:

• More concise
• Verifies the complete object state in one assertion
• Less code to maintain

Cons:

• Unclear failure messages: doesn't show which attribute differs
• Depends on Pydantic's __eq__ implementation (though reliable)
• Harder to debug: need to inspect the full object to find the difference
• Still verbose due to needing to construct the expected object

Why I chose Approach 1:

For factory method tests, the primary goal is to verify that the transformation logic works correctly - i.e., that the factory method correctly maps from domain objects or DTOs to the model. Individual attribute assertions make it immediately clear which transformation failed, which is crucial for debugging. Since these models use Pydantic, __eq__ is reliable, but the clarity benefit of Approach 1 outweighs the conciseness of Approach 2 for these tests.