Add automated tests for OCPP session failure detection

[snabo1988]

Goal

Introduce automated tests to validate OCPP session lifecycle handling,
with a focus on failed and silent-failed sessions.

Manual testing is no longer sufficient as session logic becomes more complex.

---

Related Issues

• Related to Treat Preparing -> Available transition (without Charging) as a failed session #8 (Silent failure detection: Preparing → Available without Charging)

---

Scope

Tests should cover OCPP 1.6 StatusNotification flows related to session
creation, failure detection, and cleanup.

---

Required Test Scenarios

1. Silent failure detection (Issue #8)

Given
Available → Preparing → Available

Then

• Session is classified as failed
• handle_failed_session() is called
• Failure reason:
  PREPARING_ABORTED_BEFORE_CHARGING

---

2. Valid charging session (negative test)

Given
Available → Preparing → Charging → Available

Then

• Session is NOT classified as failed
• handle_failed_session() is NOT called

---

3. Faulted session (regression test)

Given
Preparing → Faulted

Then

• Existing fault handling logic remains unchanged

---

4. Session cleanup

• Session state is removed after Available or Faulted
• No leaks in internal session storage

---

Implementation Notes

• Use pytest
• No real EVSE or network access
• Mock Engine and FTP dependencies
• Prefer direct async calls to handle_status_notification()

---

Acceptance Criteria

• All scenarios covered by automated tests
• Tests fail if silent failure detection breaks
• Tests runnable via: pytest

[knowack1]

Looks good.

[knowack1]

We should start with test that will:

1. Run CSDS
2. Connect to OCPP server - same as EVSE does. (Send BootNotification) if required
3. Send StatusNotification with faulted and error code
4. CSDS will send GetDiagnostics - we should respond to this message
5. Fetch faulted Sessions via /sessions API
6. Assert that API lists the expected session

hints:

• For simulating EVSE we should use same ocpp package that we use in production code.
• use pytest

[snabo1988]

Before we proceed further with the integration test, we have a few clarification questions:

How should CSDS be started in pytest?
– in-process (e.g. TestClient / background uvicorn), or
– as an external process?

For this test, is it mandatory to fully handle the GetDiagnostics request sent by CSDS, or is a minimal stub response sufficient?

When validating the /sessions API, which fields should be considered authoritative to classify a session as faulted (e.g. status, error_code, termination_reason)?

We can start implementing the test in parallel, but want to align on these points to avoid rework.