docs: planurile, proiectarile si rapoartele de lucru intra in versionare
Folderul docs\ era pana acum in afara oricarui control de versiuni - nici git, nici SVN - desi contine planurile pe puncte, proiectarile si rapoartele de cercetare pe care se sprijina modificarile din cod. O stergere acolo era definitiva. Fisierele intermediare (handoff-uri intre sesiuni, diff-uri deja aplicate) au fost sterse inainte, nu versionate: ce era durabil in ele a intrat in antetele fisierelor de test la care se refereau. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
This commit is contained in:
173
docs/cercetare/rec_s5_teste.md
Normal file
173
docs/cercetare/rec_s5_teste.md
Normal file
@@ -0,0 +1,173 @@
|
||||
# S5 — acoperirea de teste pentru scrierea articolelor (decizii 38-41)
|
||||
|
||||
Raport de testare pentru functionalitatea S5 (`docs\handoff_s5.md`), care nu avea niciun test la
|
||||
inceputul acestei lucrari. Trei fisiere de test atinse, toate in
|
||||
`COMUN\utile\Teste\editare_factura\`, plus diff-ul: `docs\diff_s5_teste.patch`.
|
||||
|
||||
Niciun fisier de productie nu a fost atins (`omodificari.vc2`, `ofacturare_editare.prg`,
|
||||
`ofacturare_comun.vc2`, `comun.vc2`, `ofacturare.vc2` — toate neschimbate de acest agent). Nu s-a
|
||||
scris in Oracle (sectiunea B din suita noua foloseste un mock pe `goExecutor`, nu conexiunea
|
||||
reala) si nu s-a dat commit.
|
||||
|
||||
## A. `test_page3_articole.prg` — asteptari actualizate
|
||||
|
||||
`verifica_editare_grid` verifica acum realitatea de azi: `ColumnCount=15` (era 14),
|
||||
`Type('tvd.pret_achizitie')=='N'`, `Type('tvd.id_vanzare_set')=='N'`, iar `ReadOnly` la nivel de
|
||||
coloana acopera si noua coloana 7 (`pret_achizitie`) si coloana 8 devenita `pret_cu_tva`
|
||||
(checkbox-ul `_checkbox1` mutat odata cu ea).
|
||||
|
||||
Suita ramane la **14 PASS / 2 FAIL** (numarate ca ocurente literale `PASS`/`FAIL` in log, nu prin
|
||||
regexul `raport_teste.ps1`, care pentru aceasta suita specifica subraporteaza — vezi sectiunea D).
|
||||
Cele doua FAIL sunt aceleasi doua asertii de dinainte (`llStructuraOk`, `llReadOnlyOk`), acum cu
|
||||
continut actualizat. **Gasit un motiv suplimentar de esec**, dincolo de artefactul headless deja
|
||||
cunoscut: vezi sectiunea D.
|
||||
|
||||
## B. `test_s5_validari_articole.prg` — suita noua, headless, 35 PASS / 0 FAIL
|
||||
|
||||
Doua sectiuni.
|
||||
|
||||
**Sectiunea A** — cele 5 validari noi din `inainte_de_do_termin` (`omodificari.vc2:14328-14366`),
|
||||
apelate DIRECT pe o instanta reala de `frm_modific2024` (document real, descoperit prin
|
||||
`descopera_caz_test.prg`, cazul `FACTURA_ARTICOLE`):
|
||||
- caz de control (document valid) → `.T.`, nicio validare declansata;
|
||||
- `cantitate<=0` → blocheaza, mesaj cu "cantitatea";
|
||||
- `id_articol` nul/0 → blocheaza, mesaj cu "articol";
|
||||
- zero linii active + document cu rand in `tvanz` → confirmare (ambele ramuri Da/Nu verificate);
|
||||
- linie noua cu `pret_achizitie` 0 SAU NULL → confirmare (ambele ramuri verificate, plus varianta
|
||||
NULL separat de varianta 0).
|
||||
|
||||
Un singur caz **nu s-a putut testa asa cum era planificat** — vezi constatarea de mai jos
|
||||
(`pret NULL`).
|
||||
|
||||
**Sectiunea B** — garda de no-op si SQL-ul generat de `ScrieArticoleFacturaEditate`, complet
|
||||
headless, pe cursoare construite in test (`crstvdtest`/`crstvanztest`, structura identica cu
|
||||
`CreeazaCursorArticoleGol`), cu `goExecutor` inlocuit temporar de un mock (`dummyexecutor`) care
|
||||
doar inregistreaza textul comenzilor si intoarce o valoare configurabila — conexiunea reala la
|
||||
`MARIUSM_AUTO` ramane neatinsa tot timpul acestei sectiuni.
|
||||
- garda de no-op, patru cazuri, toate verificate sa returneze `.T.` **fara niciun apel**
|
||||
`goExecutor.oExecuta`: `tnIdVanzare<=0` (0 si -5), alias articole neinchis, alias vanzare fara
|
||||
exact 1 rand (0 si 2 randuri), **`Reccount(alias articole)=0`** (cazul critic din handoff —
|
||||
protectia impotriva golirii facturii la un esec de incarcare Oracle);
|
||||
- clasificarea liniilor, verificata prin SQL-ul EFECTIV generat pe un cursor cu cate un rand din
|
||||
fiecare categorie (pastrata-modificata, pastrata-nemodificata, stearsa, noua, noua-si-stearsa,
|
||||
componenta de set): exact 1 comanda "marcheaza tot sters", exact 3 `UPDATE` (liniile pastrate
|
||||
555/556/558 — inclusiv cea nemodificata si componenta de set, conform deciziei 38 "invie TOATE
|
||||
liniile pastrate"), exact 1 `INSERT` (linia noua), 0 comenzi pentru linia stearsa si pentru cea
|
||||
noua-si-stearsa ("se ignora"), exact 1 recalcul;
|
||||
- `INSERT`-ul verificat pe continut: `pret_achizitie` citit din cursor, `explicatie` cu apostrof
|
||||
escapat corect (`OracleSpecialCharacters`), `id_vanzare`/`id_articol` corecte;
|
||||
- recalculul: `discount` NULL in cursor → parametru `NULL` (pastreaza valoarea din baza, decizia
|
||||
41); `discount=5` → parametru `5.0000`;
|
||||
- oprirea la primul esec Oracle: mock configurat sa esueze exact la a doua comanda (in mijlocul
|
||||
SCAN-ului de `UPDATE`) → functia intoarce `.F.` si **nu mai incearca a treia comanda** (2 comenzi
|
||||
total, nu 3+) — confirma ca bucla se opreste la primul esec, nu doar la primul pas.
|
||||
|
||||
### Constatare: validarea `Isnull(pret)` e cod neatingibil pe fluxul real
|
||||
|
||||
Planul initial testa si "pret NULL pe o linie activa → blocheaza". Incercarea de a forta
|
||||
`tvd.pret` la `.NULL.` (fie pe o linie persistata, fie pe una noua adaugata prin `APPEND BLANK` pe
|
||||
ACELASI cursor) arunca **eroarea VFP 1581 "Field PRET does not accept null values"** — verificat
|
||||
empiric, nu presupus. Cauza: `tvd`, populat de `IncarcaArticoleFactura` din `VVANZARI_ARTICOLE`
|
||||
(singura cale reala cand `ofacturare_editare.prg` e incarcat), mosteneste structural restrictia
|
||||
`NOT NULL` a coloanei `VANZARI_DETALII.PRET` din Oracle — restrictia e la nivel de COLOANA a
|
||||
cursorului, deci se aplica si liniilor noi adaugate ulterior, nu doar celor citite din baza.
|
||||
|
||||
Concluzie: **validarea `IF Isnull(pret) ... blocheaza` din `inainte_de_do_termin`
|
||||
(`omodificari.vc2:14340-14344`) nu poate fi declansata pe fluxul real** — nici pe o linie
|
||||
existenta, nici pe una noua construita prin fluxul aplicatiei (`AdaugaLinieTvdDinArticol`/
|
||||
`CreeazaPoArticolNouTvd`, care oricum populeaza mereu `pret`). Nu e un bug care sa piarda date sau
|
||||
sa produca un comportament gresit — e o garda defensiva care, in conditiile de azi, nu se poate
|
||||
declansa niciodata. Marcat in log ca **`FAIL asteptat`** (exclus de `raport_teste.ps1` din
|
||||
numaratoarea de regresii), cu explicatia inclusa in linie. **Raportat, nu reparat** — in afara
|
||||
mandatului acestui agent.
|
||||
|
||||
## C. `test_ui_s5_grid_pret_achizitie.prg` — verificare UI, 14 PASS / 0 FAIL
|
||||
|
||||
Coloanele gridului nu se materializeaza sub `-A -T` (memoria recurenta), deci verificarea vizuala
|
||||
s-a facut cu formular REAL, vizibil (`vfp_ui_harness.ps1`), pe documentul deja folosit de
|
||||
`test_ui_sterge_linie.prg`/`test_ui_grid_articole.prg` (cod=1139934, an=2021, luna=12,
|
||||
id_vanzare=882 — are rulaje, altfel `Show()` ascunde tot `pgfArticole`).
|
||||
|
||||
Verificat:
|
||||
- gridul are **15 coloane**, coloana `cPretAchizitieArt` exista, legata pe `tvd.pret_achizitie`,
|
||||
eticheta "Pret achizitie";
|
||||
- linie existenta (`id_vanzare_det<>0`): `pret_achizitie` **nu** primeste focus;
|
||||
- **linie de SET (caz sintetic)**: `cantitate`/`pret`/`pret_achizitie`/checkbox `pret_cu_tva`
|
||||
**niciunul** nu primeste focus, si marcajul vizual (`DynamicForeColor`) e albastru
|
||||
`RGB(0,70,153)`, exact formula din cod;
|
||||
- marcajul de linie **stearsa** (gri `RGB(150,150,150)`) e **neregresat**;
|
||||
- linie **noua** (`id_vanzare_det=0`, `id_vanzare_set=0`): `pret_achizitie` **primeste** focus,
|
||||
iar `cantitate`/`pret` raman editabile ca inainte.
|
||||
|
||||
Captura: `COMUN\utile\Teste\editare_factura\screenshots\step_0_grid_s5.png` — se vede coloana
|
||||
"Pret achizitie" in grid si prima linie grizata (sters=1).
|
||||
|
||||
**Caz sintetic, explicit**: documentul real nu are linii de set (in toata schema `MARIUSM_AUTO`
|
||||
exista doar 4 randuri in `VANZARI_SETURI` — insuficient ca sa descopere un caz real prin
|
||||
proprietate, si oricum absenta/prezenta pe atat de putine documente nu ar fi dovada in niciun
|
||||
sens). Cazul de set a fost construit prin marcarea manuala a unui rand real din `tvd`
|
||||
(`id_vanzare_set = 777`), tiparul deja folosit in `test_adauga_linie_valuta.prg` pentru cazul de
|
||||
valuta. Verificarile de focus s-au facut prin apel DIRECT al metodei `.When()` a controlului
|
||||
(echivalentul programatic al "celula primeste focus"), nu prin input real — masina e partajata cu
|
||||
Marius.
|
||||
|
||||
## D. Constatare separata: `loGrid.ColumnN` nu functioneaza pe acest grid (nu doar headless)
|
||||
|
||||
La scrierea testului UI, prima varianta folosea acelasi tipar ca `test_page3_articole.prg`
|
||||
(`loGrid.Column1.DynamicForeColor`) si a picat cu **eroarea VFP 1925 "Unknown member COLUMN1"** —
|
||||
desi gridul era complet materializat (`ColumnCount` citea corect 15, `Show()` real, nu headless).
|
||||
Cauza: coloanele acestui grid sunt redenumite explicit (`Column1.Name = "cDenumireArt"`,
|
||||
`Column7.Name = "cPretAchizitieArt"` etc.) — in VFP, o coloana de grid redenumita asa **nu mai
|
||||
raspunde la accesul numeric implicit** (`.Column1`), accesul valid ramane DOAR pe numele nou
|
||||
(`.cDenumireArt`). Corectat in `test_ui_s5_grid_pret_achizitie.prg` (`loGrid.cDenumireArt...`).
|
||||
|
||||
Consecinta pentru `test_page3_articole.prg`: cele doua asertii ramase FAIL (`llStructuraOk`,
|
||||
`llReadOnlyOk`) nu pica *doar* din artefactul headless cunoscut (grid nematerializat) — **ar pica
|
||||
oricum**, chiar si intr-un rulaj cu formular vizibil, din cauza tiparului de acces
|
||||
`loGrid.Column1`/`.Column5`/`.Column6`/`.Column7`/`.Column8`/`.Column14`/`.Column15`, folosit deja
|
||||
in codul S4 preexistent (nu introdus de aceasta lucrare). Nu am corectat acest tipar in
|
||||
`test_page3_articole.prg` — mandatul explicit a fost sa actualizez ASTEPTARILE (numarul de
|
||||
coloane, semantica de editabilitate), nu sa repar accesul la obiect, iar suita trebuia sa ramana la
|
||||
14/2 fara sa "iasa alt numar". Semnalat aici ca sa nu se piarda: daca cineva vrea vreodata sa faca
|
||||
`verifica_editare_grid` sa treaca real (nu doar sa esueze "cunoscut"), trebuie schimbat atat
|
||||
harnessul (formular vizibil, nu `-A -T`) CAT SI accesul la coloane (`loGrid.cDenumireArt` etc., nu
|
||||
`loGrid.Column1`).
|
||||
|
||||
## E. Regresie finala
|
||||
|
||||
`raport_teste.ps1 -Dir COMUN\utile\Teste\editare_factura -Tot`, dupa ultima editare (verificat pe
|
||||
mtime):
|
||||
|
||||
| Suita | PASS | FAIL |
|
||||
|---|---|---|
|
||||
| test_adauga_linie_articol | 20 | 0 |
|
||||
| test_adauga_linie_valuta | 16 | 0 |
|
||||
| test_incarca_vanzare_din_nota | 5 | 0 |
|
||||
| test_page3_articole | 10*/14** | 0*/2** |
|
||||
| test_s5_validari_articole (nou) | 35 | 0 |
|
||||
| test_ui_s5_grid_pret_achizitie (nou) | 14 | 0 |
|
||||
| test_ui_sterge_linie | 8 | 0 |
|
||||
| test_verdict_act_rul | 26 | 0 |
|
||||
|
||||
\* cifra `raport_teste.ps1` (regex pe inceput de linie — subraporteaza pentru aceasta suita
|
||||
specifica, vezi mai jos). \*\* cifra reala, numarata ca ocurente literale `PASS`/`FAIL` in log —
|
||||
aceasta e conventia din `docs\handoff_s5.md` ("test_page3_articole 14/2"), verificata identica
|
||||
inainte si dupa editarea mea.
|
||||
|
||||
**Atentie separata pentru viitor**: `raport_teste.ps1` numara doar liniile care incep cu
|
||||
`PASS`/`FAIL` dupa spatii (`^\s*PASS`); `test_page3_articole.prg` scrie o parte din verdicte ca
|
||||
`eticheta = PASS/FAIL` (verdictul la finalul liniei, nu la inceput) — pentru ACEASTA suita specifica,
|
||||
raportul automat arata 10/0 in loc de 14/2 reale. Nu e o problema introdusa acum (tiparul exista
|
||||
deja in cod dinainte), dar inseamna ca **pentru `test_page3_articole`, raportul automat nu e de
|
||||
incredere** — verificarea trebuie facuta manual (`grep -o PASS/FAIL`, cum s-a facut aici), nu doar
|
||||
cu `raport_teste.ps1`.
|
||||
|
||||
Toate celelalte suite: identice cu baseline-ul din `docs\handoff_s5.md`, nicio regresie.
|
||||
|
||||
## F. Ce nu s-a acoperit si de ce
|
||||
|
||||
- **Test cu scriere reala in Oracle** (aprobat de Marius pentru S5, dar separat de mandatul acestui
|
||||
agent — interzis explicit sa scrie in baza) — ramane pentru o lucrare ulterioara, dupa modelul
|
||||
`test_writeback_buton1.prg`.
|
||||
- **R5** (linie cu valuta fara rand in `VANZARI_CURSURI`) — ramane deschis din `handoff_s5.md`, nu
|
||||
s-a adaugat un test nou pentru el, in afara mandatului de "validari + helper + grid".
|
||||
Reference in New Issue
Block a user