Am crezut că testarea unităților este imposibilă în 1C (nu există obiecte omniprezente, clase obișnuite etc.). Uneori, au apărut procesări speciale de la Infostart, dar de cele mai multe ori se sperie tematică de testare, în loc să o atragă. Apoi am aflat despre xUnitFor1C. Sa dovedit că testarea în 1C în general nu este atât de dificilă, chiar și în comparație cu alte limbi. În acest articol voi vorbi despre prima mea experiență.
Vreau să-mi exprim recunoștința pentru articolul așa-quest. A fost impulsul necesar studierii xUnitFor1C, care va fi discutat mai jos.
Și, de asemenea, pentru dezvoltatorii de xUnitFor1C pentru un set minunat de instrumente.
xUnitFor1C este un set de procesare externă 1c, facilitând și, cel mai important, comandând testarea. În acest articol, va fi folosit numai xddTestRunner.epf (test runner).
Dezvoltarea procesării pentru logarea lucrării robotului și ieșirea raportului reportat. O complicație suplimentară este ieșirea din raportul mesajelor de serviciu care au avut loc în timpul lucrului robotului (de exemplu, atunci când se efectuează documente). Aplicăm "dezvoltare prin testare".
Noi pregătim mediul înconjurător.
Un set de teste este o procesare care conține funcția de export. Obțineți lista de teste (unitatea de testare). Documentația sugerează un șablon pentru o astfel de prelucrare. Noi o creăm și o salvăm. Modulul de procesare arată astfel:
Executați xddTestRunner.epf. Pentru mine, interfața a fost neașteptat de prietenoasă. Descărcați testele din catalog. Verificați. Ar trebui să apară un test. Testul ar trebui să eșueze. Corectați testul.
Acum testul trebuie să aibă succes.
Ciclul de dezvoltare.
1) Creați un test rupt
Reîncărcați lista de teste, verificăm testele acum 2 și cel de-al doilea eșuat.
2) Doar suficient pentru a face testul de succes.
Adăugăm partea din tabel în procesare cu câmpurile "completat" și "text".
Adăugarea la modul
Verificăm dacă testul a trecut.
3) Refactorizarea.
Prin această abordare, codul este imediat acoperit de teste și poate fi modificat fără teama că modificările vor avea "consecințe necunoscute".
Conform TDD, pașii 1,2,3 se repetă tot timpul, iar durata de repetare trebuie să fie cât mai mică posibil.
Independența testelor.
Pentru a asigura independența, sunt prevăzute următoarele proceduri:
Repetați dacă este necesar.
Repetați dacă este necesar.
Întregul proces de scriere poate fi văzut la comitetele din depozit pe github
Nu am gasit cum sa faca descarcarea gratuita, deci in acel depozit exista si o arhiva atasata articolului.
Mulțumesc pentru atenție, sper că vor exista oameni care după acest articol vor adopta principiile descrise și lumea va deveni puțin mai bună.
P.S. Cine este aici?
Când apare întrebarea "Cum să scrieți o interogare", "Cum se face o formă imprimată", răspunsul este imediat localizat. În cele din urmă, puteți vedea cum se face într-o configurație tipică. Dar când au fost întrebări, "Și ce ar trebui să scriu în teste?" "Cum să testeze rapoartele?" O formulă ușor de gestionat? în configurația standard a răspunsurilor pe care nu le-am găsit. Ei bine, a trebuit să-mi inventez cârjele ..
Dar cineva folosește deja aceste abordări (de când cineva a scris xddTestRunner). Probabil că această persoană a întâmpinat multe dificultăți și le-a decis. Prin urmare, în cazul în care cineva vrea să vorbească, a aplicat încă un tratament, în care totul nu sa dovedit atât de liniștit și frumos. Sper pentru critici constructive și referințe la citire. =)
Descărcați fișiere
Trimiteți-le prietenilor: