ADORSYS-GIS / ADORSYS-GIS/lightbridge-governance
[Ticket]: de-duplicate checkpoint()/field() across eight copilot_push tests
- Lingua principale
- Rust
- Stelle
- 1
- Fork
- 2
- Merge medio
- 14h 36m
- PR unite (30g)
- 107
Descrizione
## Summary
Seven `copilot_push_*` integration tests each carry their own byte-identical copy of the same two helpers, `checkpoint()` and `field()`.
## Affected
```
tests/copilot_push_flaky.rs tests/copilot_push_partial.rs
tests/copilot_push_rotation.rs tests/copilot_push_held.rs
tests/copilot_push_interrupted.rs tests/copilot_push_invariants.rs
tests/copilot_push_loss.rs (+ copilot_push_quarantine.rs, split from flaky)
```
## Why it was not fixed in #228
The duplication was noticed while splitting `copilot_push_flaky.rs` to satisfy the LoC gate. Lifting the helpers into `tests/support/` touches eight files, which does not belong in a gate fix on an already-large branch. Following the existing convention was the smaller, more reviewable choice at the time.
## Scope
Move both helpers into `tests/support/` (a small `checkpoint.rs` module beside `copilot.rs`, exported from `support/mod.rs`) and delete the copies. Purely mechanical; no assertion should change.
Note `support/copilot.rs` is at 196 lines against the 200 ceiling, so the helpers need their own module rather than being appended there.
## AI Usage Declaration
AI-assisted. File list produced by grep, not recalled. A human owns intent, verification and consequences.
Guida per i contributori
Apri la guida per i contributori
Direzione di ricerca
Start by comparing the duplicated checkpoint() and field() helpers in the eight listed tests, then read tests/support/mod.rs and tests/support/copilot.rs for the support-module convention and line-limit context. Verify that the helpers can be isolated in a support/checkpoint.rs module and exported without changing assertions. Done means all listed copilot_push tests use the shared helpers and continue passing unchanged.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- rust
- Ambito
- testing-qa
- Tipo di issue
- Refactoring
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Stato di attività
- Attiva
- Chiarezza
- Specificata chiaramente
- Idoneità per principianti
- 78/100