feat: handle p and q measurement modification in battery

[KoloMenek]

PR Summary

[coderabbitai]

Warning

Rate limit exceeded

@KoloMenek has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 36 minutes and 4 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 3686759b-44cf-4615-9905-1d45c7ec0af1

📥 Commits

Reviewing files that changed from the base of the PR and between 944f42f and edb585a.

📒 Files selected for processing (2)

• src/main/java/org/gridsuite/modification/modifications/BatteryModification.java
• src/test/java/org/gridsuite/modification/modifications/BatteryModificationTest.java

📝 Walkthrough

Walkthrough

BatteryModification was refactored to inherit from AbstractInjectionModification instead of managing modificationInfos directly. The check() and apply() methods now cast the inherited field locally. BatteryModificationTest was expanded with measurement constants and assertions, including a new test case for measurement updates with report node validation and helper methods for structured assertions.

Changes

BatteryModification Refactoring and Measurement Validation

Layer / File(s)	Summary
BatteryModification inheritance refactoring src/main/java/org/gridsuite/modification/modifications/BatteryModification.java	The check(Network) method casts the inherited modificationInfos to BatteryModificationInfos locally and uses it for voltage-level, reactive limit, active-power, and droop percentage validation. The apply(Network, ReportNode) method delegates to a new private modifyBattery(Battery, ReportNode) that casts modificationInfos and applies battery attributes via helper methods.
Test infrastructure and measurement constants src/test/java/org/gridsuite/modification/modifications/BatteryModificationTest.java	Added imports for ReportNode, Measurements, and Measurement extension types. Introduced static AssertJ import and shared constants for measurement values and validity flags. Modified the modification builder to use these constants instead of inline literals.
Measurement validation tests and helpers src/test/java/org/gridsuite/modification/modifications/BatteryModificationTest.java	Added measurement assertion after applying the base modification. Introduced testMeasurementsUpdatedWithNewMeasurements that applies an initial modification, then applies a second modification updating measurement values and validity, asserting both the updated battery measurements and corresponding report nodes with old/new value pairs. Added private helper methods to assert measurement extension contents and report node structure.

Suggested reviewers

• achour94

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Description check	❓ Inconclusive	The PR description is empty/missing beyond the template, providing no context about the changes despite modifications to BatteryModification and tests.	Provide a detailed description explaining what measurement modifications are being added, why they were needed, and how they work.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: adding support for handling active (p) and reactive (q) measurement modifications in battery components.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[benrejebmoh]

Both BatteryModificationTest.assertMeasurements() helpers (in network-modification and network-modification-server) only verify that measurement extensions are created when they don't previously exist on the battery. The
upsertMeasurement method in AbstractInjectionModification has a separate code path for updating an existing measurement — it reads oldValue/oldValidity, modifies them, and adds report nodes. That path is completely untested for Battery.

Suggestion: add a second test scenario where the battery already has a Measurements extension before the modification is applied, verify that the values are updated, (and optionally check that the report nodes reflect the old→new change)

[benrejebmoh]

This appears to be an accidental formatting change.
The .value(...) continuation should be indented to align with .name(...)

[KoloMenek]

Fixed

[benrejebmoh]

instead of using == on Double assertion, prefer using something like:
assertThat(activePowerMeasurements).allSatisfy(m -> {
assertThat(m.getValue()).isEqualTo(MEASUREMENT_P_VALUE);
assertThat(m.isValid()).isEqualTo(MEASUREMENT_P_VALID);
});

[KoloMenek]

Fixed

[KoloMenek]

Both BatteryModificationTest.assertMeasurements() helpers (in network-modification and network-modification-server) only verify that measurement extensions are created when they don't previously exist on the battery. The upsertMeasurement method in AbstractInjectionModification has a separate code path for updating an existing measurement — it reads oldValue/oldValidity, modifies them, and adds report nodes. That path is completely untested for Battery.

Suggestion: add a second test scenario where the battery already has a Measurements extension before the modification is applied, verify that the values are updated, (and optionally check that the report nodes reflect the old→new change)

Did the changes with a new test called testMeasurementsUpdatedWithNewMeasurements

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud