Adriano/TieMeasureFlow
1
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

TestTaskComplete: 6 test rossi dopo la camera di stazione (#72) #79

New Issue
Closed
opened 2026-10-17 07:41:33 +00:00 by Adriano · 3 comments
Adriano commented 2026-10-17 07:41:33 +00:00
Owner
Copy Link
Copy Source

RIF: gitea:Adriano/TieMeasureFlow V3.0.0 cd40b81
COSA: src/frontend/flask_app/tests/test_measure.py::TestTaskComplete, 6 test rossi deterministici, anche da soli: AttributeError 'NoneType' object has no attribute 'get' in src/frontend/flask_app/blueprints/measure.py:416 (meas_resp.get). PRESUNTO: il commit 192d4b5 (#72) aggiunge in task_complete una chiamata api_client.get_station_by_code (_station_camera) che consuma una risposta dei mock in sequenza dei test, e meas_resp arriva None.
PROVA: pytest src/frontend/flask_app/tests/test_measure.py -k TestTaskComplete (Python 3.13, daitarn, albero cd40b81 senza modifiche al frontend) -> 6 failed, 34 deselected
PROSSIMO: verificare la presunzione, poi correggere i mock dei test oppure il codice se il difetto è vero a runtime.

RIF: gitea:Adriano/TieMeasureFlow V3.0.0 cd40b81 COSA: src/frontend/flask_app/tests/test_measure.py::TestTaskComplete, 6 test rossi deterministici, anche da soli: AttributeError 'NoneType' object has no attribute 'get' in src/frontend/flask_app/blueprints/measure.py:416 (meas_resp.get). PRESUNTO: il commit 192d4b5 (#72) aggiunge in task_complete una chiamata api_client.get_station_by_code (_station_camera) che consuma una risposta dei mock in sequenza dei test, e meas_resp arriva None. PROVA: pytest src/frontend/flask_app/tests/test_measure.py -k TestTaskComplete (Python 3.13, daitarn, albero cd40b81 senza modifiche al frontend) -> 6 failed, 34 deselected PROSSIMO: verificare la presunzione, poi correggere i mock dei test oppure il codice se il difetto è vero a runtime.
Adriano added the bug label 2026-10-17 07:41:33 +00:00
Adriano added the assegnata:daitarn label 2026-10-17 12:08:11 +00:00
Adriano commented 2026-10-17 12:08:11 +00:00
Author
Owner
Copy Link
Copy Source

🔵 daitarn — preso in carico 2026-10-17T12:08:08Z
ramo: lavoro/daitarn · capacità: build-windows, gpu

🔵 daitarn — **preso in carico** 2026-10-17T12:08:08Z ramo: `lavoro/daitarn` · capacità: build-windows, gpu
Adriano commented 2026-10-17 12:08:25 +00:00
Author
Owner
Copy Link
Copy Source

ANALISI (passo 1, Opus 5.5) — causa diversa da quella presunta: non 192d4b5, ma stato che fuga fra i test.
COSA: test frontend dipendenti dall'ordine. src/frontend/flask_app/tests/test_measure.py (righe 15-20, 50-55, 82-87) fa monkeypatch.setenv("STATION_CODE","ST-TEST") + importlib.reload(config) + importlib.reload(blueprints.measure). Al teardown monkeypatch toglie la variabile ma i moduli ricaricati restano con Config.STATION_CODE="ST-TEST".
EFFETTO:

  • TestTaskComplete (test_measure.py:393) mette in side_effect un elemento per /api/production-runs/current, che blueprints/measure.py:_current_run_id (riga 175) chiama solo se c'e' una stazione. Passa solo se gira dopo i test che lasciano ST-TEST; isolato o sotto xdist il None finisce come risposta delle misure -> measure.py:416 AttributeError.
  • test_recipe_rules_ui.py::test_avvia_starts_once_the_lot_is_there (riga 177, helper _task_list riga 145) all'opposto suppone nessuna stazione: con ST-TEST fuggito, _current_run_id consuma una chiamata in piu' -> StopIteration.
    VERIFICATO: pytest TestTaskComplete da solo -> 6 failed; con STATION_CODE=ST-TEST -> 6 passed; test_measure.py intero -> 40 passed; suite -n 8 sul ramo integrato (V3.0.0 0e92959) -> questi 7 rossi.
    MODIFICHE:
  1. test_measure.py: i fixture che ricaricano config tornano allo stato pulito al teardown (dopo yield: delenv gia' fatto da monkeypatch, poi importlib.reload(config) e importlib.reload(blueprints.measure)), oppure usano monkeypatch.setattr("blueprints.measure.Config.STATION_CODE", "ST-TEST") come test_base_inactivity_keydown.py:20. Scegliere il minimo che elimina la fuga.
  2. TestTaskComplete: fixture autouse che imposta esplicitamente la stazione (monkeypatch.setattr su blueprints.measure.Config.STATION_CODE = "ST-TEST"), cosi' l'elemento "current run" del side_effect e' sempre consumato.
  3. test_recipe_rules_ui.py: _task_list (o un fixture autouse del modulo) fissa Config.STATION_CODE = None con monkeypatch, coerente con i side_effect a due elementi.
    TEST:
  • pytest test_measure.py::TestTaskComplete da solo -> verde.
  • pytest test_recipe_rules_ui.py dopo test_measure.py nello stesso processo -> verde.
  • pytest -p no:randomly src/frontend/flask_app/tests -n 8 -> nessun rosso tranne test_offline (CRLF, issue a parte).
  • suite frontend seriale -> stessi numeri o meglio di prima.
    NON TOCCARE: src/frontend/flask_app/blueprints/, services/, config.py, templates/, static/, src/backend/, packaging/.
ANALISI (passo 1, Opus 5.5) — causa diversa da quella presunta: non 192d4b5, ma stato che fuga fra i test. COSA: test frontend dipendenti dall'ordine. src/frontend/flask_app/tests/test_measure.py (righe 15-20, 50-55, 82-87) fa monkeypatch.setenv("STATION_CODE","ST-TEST") + importlib.reload(config) + importlib.reload(blueprints.measure). Al teardown monkeypatch toglie la variabile ma i moduli ricaricati restano con Config.STATION_CODE="ST-TEST". EFFETTO: - TestTaskComplete (test_measure.py:393) mette in side_effect un elemento per /api/production-runs/current, che blueprints/measure.py:_current_run_id (riga 175) chiama solo se c'e' una stazione. Passa solo se gira dopo i test che lasciano ST-TEST; isolato o sotto xdist il None finisce come risposta delle misure -> measure.py:416 AttributeError. - test_recipe_rules_ui.py::test_avvia_starts_once_the_lot_is_there (riga 177, helper _task_list riga 145) all'opposto suppone nessuna stazione: con ST-TEST fuggito, _current_run_id consuma una chiamata in piu' -> StopIteration. VERIFICATO: pytest TestTaskComplete da solo -> 6 failed; con STATION_CODE=ST-TEST -> 6 passed; test_measure.py intero -> 40 passed; suite -n 8 sul ramo integrato (V3.0.0 0e92959) -> questi 7 rossi. MODIFICHE: 1. test_measure.py: i fixture che ricaricano config tornano allo stato pulito al teardown (dopo yield: delenv gia' fatto da monkeypatch, poi importlib.reload(config) e importlib.reload(blueprints.measure)), oppure usano monkeypatch.setattr("blueprints.measure.Config.STATION_CODE", "ST-TEST") come test_base_inactivity_keydown.py:20. Scegliere il minimo che elimina la fuga. 2. TestTaskComplete: fixture autouse che imposta esplicitamente la stazione (monkeypatch.setattr su blueprints.measure.Config.STATION_CODE = "ST-TEST"), cosi' l'elemento "current run" del side_effect e' sempre consumato. 3. test_recipe_rules_ui.py: _task_list (o un fixture autouse del modulo) fissa Config.STATION_CODE = None con monkeypatch, coerente con i side_effect a due elementi. TEST: - pytest test_measure.py::TestTaskComplete da solo -> verde. - pytest test_recipe_rules_ui.py dopo test_measure.py nello stesso processo -> verde. - pytest -p no:randomly src/frontend/flask_app/tests -n 8 -> nessun rosso tranne test_offline (CRLF, issue a parte). - suite frontend seriale -> stessi numeri o meglio di prima. NON TOCCARE: src/frontend/flask_app/blueprints/**, services/**, config.py, templates/**, static/**, src/backend/**, packaging/**.
Adriano commented 2026-10-17 12:38:13 +00:00
Author
Owner
Copy Link
Copy Source

Soluzione

ESITO: fatto
CAUSA: non 192d4b5 ma STATION_CODE che fuggiva fra i test: setenv + importlib.reload(config/blueprints.measure) lasciava Config.STATION_CODE=ST-TEST dopo il teardown; l'esito dipendeva dall'ordine (xdist).
FILE: src/frontend/flask_app/tests/test_measure.py — TestSelectRecipe usa monkeypatch.setattr(blueprints.measure.Config.STATION_CODE) al posto del reload; TestTaskComplete fixture autouse _station=ST-TEST. src/frontend/flask_app/tests/test_recipe_rules_ui.py — fixture autouse _no_station=None, test_selection_screen_carries_the_traceability_rules senza reload.
COMMIT: f33415d (lavoro/daitarn-tmf-79), merge 15e31e2 in V3.0.0.
PROVA: ramo integrato V3.0.0 d652891 su daitarn, Python 3.13: pytest -n 8 src/backend/tests src/frontend/flask_app/tests packaging/windows/tests -> 911 passed, 4 skipped, 0 failed. Tag v3.0.0-rc2.
MANCA: setenv+reload restano in test_admin_user_pin.py:98, test_config_station.py, test_csrf_errorhandler.py:15, test_measure_production.py:17; oggi non rompono nulla (suite verde), da sistemare se ricompare un test dipendente dall'ordine.

**Soluzione** ESITO: fatto CAUSA: non 192d4b5 ma STATION_CODE che fuggiva fra i test: setenv + importlib.reload(config/blueprints.measure) lasciava Config.STATION_CODE=ST-TEST dopo il teardown; l'esito dipendeva dall'ordine (xdist). FILE: src/frontend/flask_app/tests/test_measure.py — TestSelectRecipe usa monkeypatch.setattr(blueprints.measure.Config.STATION_CODE) al posto del reload; TestTaskComplete fixture autouse _station=ST-TEST. src/frontend/flask_app/tests/test_recipe_rules_ui.py — fixture autouse _no_station=None, test_selection_screen_carries_the_traceability_rules senza reload. COMMIT: f33415d (lavoro/daitarn-tmf-79), merge 15e31e2 in V3.0.0. PROVA: ramo integrato V3.0.0 d652891 su daitarn, Python 3.13: pytest -n 8 src/backend/tests src/frontend/flask_app/tests packaging/windows/tests -> 911 passed, 4 skipped, 0 failed. Tag v3.0.0-rc2. MANCA: setenv+reload restano in test_admin_user_pin.py:98, test_config_station.py, test_csrf_errorhandler.py:15, test_measure_production.py:17; oggi non rompono nulla (suite verde), da sistemare se ricompare un test dipendente dall'ordine.
Adriano removed the assegnata:daitarn label 2026-10-17 12:38:14 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
assegnata:daitarn
assegnata:jeeg
attesa:adriano
attesa:cliente
attesa:macchina
bug
Difetto trovato in revisione o in uso
 sviluppo
Sviluppo o miglioria da fare
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Adriano
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Adriano/TieMeasureFlow#79
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?