Puncte:0

Rularea de teste pentru un modul fără a necesita o instalare completă pe site

drapel in

Construiesc un modul personalizat (pentru a fi utilizat pe mai multe proiecte) cu cod care se bazează pe chestii de la modulele de bază Drupal și de la terțe părți (de exemplu, extinderea claselor, implementarea interfețelor, adnotarea ca plugin-uri etc.). Aș dori să încep să scriu teste pentru ei, cu teste unitare pentru început.Dar până acum, toate resursele indică punerea modulului într-o instalare Drupal și testarea în acea configurație, ca și cum aș rula un site Drupal complet - chiar și pentru un test unitar.

Îmi imaginam mai degrabă că modulul meu ar avea rulerul, dependențele și nucleul Drupal să fie dependențe (sau dependențe de dezvoltare) - la fel cum sunt scrise de obicei testele JavaScript, fie că este vorba de teste unitare sau teste de browser fără cap. Adică, testarea JavaScript nu necesită să introduceți codul în alt cod înainte de a putea începe testarea.

Se poate realiza acest lucru? Sau introducerea codului modulelor mele într-o instalare Drupal este într-adevăr singura modalitate de a testa modulele Drupal?

Jaypan avatar
drapel de
Testele unitare nu pornesc întregul sistem și rulează foarte repede.Testele kernel, testele funcționale și testele JavaScript necesită bootstrap-ul sistemului și durează mai mult.
drapel in
@Jaypan Da, sunt conștient de tipurile de teste și de modul în care rulează. Întrebarea este mai degrabă „modulele de bază ale Drupal și modulele terță parte pot fi „dependențe de dezvoltare”, astfel încât să îmi pot satisface dependențele modulelor în timpul testării și să îmi rulez testele unitare fără a configura Drupal într-un mod asemănător site-ului?”
Jaypan avatar
drapel de
Nu tocmai, deoarece atunci ai testa codul extern, mai degrabă decât propria unitate de cod. În acest caz, în schimb creați mock-uri/stub-uri, care imită serviciul pe care încercați să îl apelați: https://www.drupal.org/docs/automated-testing/phpunit-in-drupal/mocking-entities-and-services- cu-phpunit-și-mocks
Jaypan avatar
drapel de
Am pus aceste ultime două comentarii împreună într-un răspuns mai cuprinzător la întrebarea inițială.
Puncte:2
drapel de

Testele unitare nu pornesc întregul sistem și rulează foarte repede. Testele kernel, testele funcționale și testele JavaScript necesită bootstrap-ul sistemului și durează mai mult.

Cu testarea unitară, nu declarați dependențe de codul străin. Acest lucru se datorează faptului că testele unitatea testează o bucată de cod, nu codul străin. Dacă a fost introdusă o eroare în codul străin, iar codul testat depindea de acel cod, testele ar eșua, chiar dacă codul testat era încă corect. Acesta ar fi un fals eșec, iar un dezvoltator ar petrece probabil timp încercând să-și dea seama de ce codul lor a eșuat, chiar dacă nu a făcut-o.

Soluția este să folosiți simulari pentru a bloca datele. O simulare este un serviciu fals, creat în cadrul testului, care simulează serviciul dependent real. Deci, atunci când codul testat efectuează un apel către codul străin, simularea returnează un răspuns (alias un stub) ca și cum codul străin ar fi răspuns, eliminând orice risc de fals pozitive din codul străin eșuat, deoarece testul dumneavoastră va răspunde întotdeauna și va răspunde întotdeauna exact așa cum ați setat.

drapel in
Înțeleg că pot bate joc de dependențe (de exemplu, servicii, argumente etc.).Mai mult mă întrebam ce se întâmplă cu clasele declarate în `use`, sau cu clasa pe care o extind, sau cu interfața pe care o implementez sau cu trăsăturile pe care le aplic. De exemplu, construiesc un plugin _extending_ core `PluginBase`. Trebuie să fac ceva special pentru testul meu în ceea ce privește „PluginBase”? Testul caută „PluginBase”? Am nevoie de „PluginBase” adevărat? Sau trebuie să folosesc un „PluginBase” fals? Testez doar o logică de bază în acel plugin, nu întregul mecanism al pluginului.
Jaypan avatar
drapel de
Aș sugera să vă uitați la câteva exemple din nucleu sau să deschideți noi bilete pentru întrebările dvs., deoarece consider că s-a răspuns la întrebarea inițială, adică folosiți imitații pentru a trata dependențele în testele unitare. Și pe măsură ce modulele de bază fac acest lucru, da, declarațiile `use` vor funcționa bine.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.