romfast/roafacturare
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b5a7108f34fce3ca78a00ece36dca2f65bda9641
roafacturare/docs/cercetare/rec_s5_teste.md
Marius Mutu b5a7108f34 docs: cercetarile comune trec in COMUN, reziduul #6 dispare, progres.md la zi 
Curatenie ceruta dupa inchiderea lui #6. Folderul cercetare\ NU se putea sterge
in bloc: plan_13 se sprijina pe el cu 85 de trimiteri, deci e baza de dovezi a
planului aflat in lucru. Impartirea:

- 14 cercetari trans-proiect trec in COMUN\docs\cercetare\ - valuta si curs,
  TVA/VANZARI, consumatorii VANZARI din toata suita, integrarile #10/#11/#12,
  watchdog VFP, proiectarea Oracle a lui S5, view-ul VVANZARI_ARTICOLE. Nu sunt
  ale ROAFACTURARE, iar #10/#11/#12 se reiau chiar din ele.
- 20 de rapoarte de executie ale lui #6, nereferite de nimic viu, sterse.
- 91 raman, neatinse.

Trimiterile catre handoff-urile si diff-urile intermediare deja desfiintate au
fost curatate peste tot (39 de fisiere): 50 catre handoff-uri, 37 catre diff-uri
aplicate, plus caile celor mutate in COMUN. Zero trimiteri rupte ramase.

progres.md preia rolul de predare: ce ramane din #6 (cele sase documente
parazite, cele doua esecuri reale din S8 pe factura din aviz), cifrele de test
citite din log, si cele doua capcane de mediu platite - .FXP vechi executat in
locul .prg-ului, si GETFONT() care atarna un formular instantiat fara goApp.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3
2026-08-11 22:31:42 +03:00

11 KiB
Raw Blame History

S5 — acoperirea de teste pentru scrierea articolelor (decizii 38-41)

Raport de testare pentru functionalitatea S5 (handoff intermediar (sters)), care nu avea niciun test la inceputul acestei lucrari. Trei fisiere de test atinse, toate in COMUN\utile\Teste\editare_factura\, plus diff-ul: diff aplicat (sters).

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 handoff intermediar (sters) ("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 handoff intermediar (sters), 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 intermediar (sters), nu s-a adaugat un test nou pentru el, in afara mandatului de "validari + helper + grid".