Kaip modifikuoti testus į ReactJS kodų bazes be testų

Jau keletą metų domiuosi programinės įrangos testavimu ir palengvinimu. Dabar šis susidomėjimas labiau sutelktas į anksčiau buvusias sąsajos programas. Tiksliau, reactjs programoms. Praėjo keli mėnesiai, kai pasineriu į penkerių–dešimties metų senumo „reactjs“ kodą, kuris suteikia man įžvalgų ir iššūkių.

Aš asmeniškai jau keletą metų kuriu reactjs kodą; vienas pirmųjų atvirojo kodo projektų, kuriais pasidalinau, vadinamas testable . Jis buvo išleistas maždaug 2020 m., ir nuo tada dalį savo mokymosi kelio skiriu reactjs.

Pastaruoju metu dirbau su kitais atvirojo kodo projektais, kuriuose pagrindinis dėmesys skiriamas tokių dalykų kaip json-tool ir text-tool testavimo daliai; abi programos yra atvirojo kodo ir yra įdiegtos „Snapcraft“. Be tų, aš dažnai vykdau eksperimentus saugykloje, vadinamoje reactjs-playground . Tai vieta, kur eksperimentuoju su reactjs funkcijomis ir skiriu tam savo mokymosi valandas. Patirtis, kurią per tuos metus sukaupiau vykdydama artimo šaltinio ir atvirojo kodo projektus, suteikė man pagrindą, leidžiantį nustatyti kai kuriuos bendrus spąstus ir pranašumus.

Spąstai

Kūrėjai, kurie prisijungia prie reactjs modelio ir įrankių, supranta, kad bibliotekos siūlomus blokus lengva suprasti ir sudaryti. Abstrakčiausia komponento sąvoka gali būti naudojama norint greitai sudaryti vartotojo sąsajas. Tačiau tai taip pat gali būti klaidų šaltinis, kai kalbama apie komponento hierarchijos struktūrą. Sistemų skilimas yra daugelį metų tyrinėjamas dalykas .

Didieji komponentai

Programinės įrangos abstrakcijos vienybės dydis taip pat buvo diskusijų objektas; kai kurie teigia, kad metodai ir klasės turi turėti nedaug eilučių, o kiti nori turėti didesnį, gerai struktūrizuotą gabalą. Kaip ir bet kuriame programinės įrangos projekte, neatsižvelgiant į dydį, aš ketinu teikti pirmenybę dydžiui, kuris suteikia daugiau konteksto ir sumažina pažinimo apkrovą skaitant kodą.

Sutapimas ar ne, mano patirtis rodo, kad tai įmanoma, kai turiu gerai nustatytas kodo, prie kurio dirbu, ribas ir verslo kontekstą. Dar neradau tam stebuklingo skaičiaus, tačiau mano matavimas tapo šuolių, kuriuos turiu atlikti tarp failų, skaičiumi, kad suprasčiau, ką turiu padaryti.

Kiek šuolių turiu padaryti, tuo labiau man reikia laikyti galvoje kontekstą ir informaciją; tai tampa sunku išlaikant kodo bazę. Šių komponentų išskaidymas yra iššūkis, tačiau į tai reikia atsižvelgti, kad būtų geriau prižiūrima kodo bazė.

Pasaulinė valstybė

Profesiniam tobulėjimui pasaulinė valstybė yra pagrindinis reikalavimas; „Reactjs“ programoms tai nesiskiria. Pasaulinę būseną nesunkiai pastebi programos vartotojai. Jei ką nors perkate ir įdedate prekę į krepšelį, galite matyti įdėtų prekių skaičių; tai yra pasaulinė valstybė.

Reactjs programose kažkada plačiai naudojamas visuotinis būsenos valdymo paketas redux dabar sumažino jo naudojimą, o mažesniuose kontekstuose aplink programos ribas. Tačiau bendruomenė dalijasi skirtingomis nuomonėmis dėl būtinybės naudoti redux globaliam valstybės valdymui; dėl to atsirado keletas tinklaraščių šia tema:

• Neturėtumėte naudoti Redux savo React programai .
• Kodėl jums nebereikia Redux?

Nepaisant bendruomenės atstūmimo, react-redux, kuri yra biblioteka, naudojama redux surišti su reactjs komponentais, per pastaruosius penkerius metus, atsižvelgiant į npm tendencijas, populiarėjo . 2025 m. vasario 1 d. npm rodomas redux atsisiuntimų skaičius yra 6 752 764.

Jei jums įdomu, kokia yra to alternatyva, atsakymas yra reactjs kontekstas ir užklausos.

Programoms, kurios priklauso nuo redux paketo, pats savaime yra iššūkis atsikratyti. Pasaulinė būsena yra viena iš priklausomybių, mažinančių programos testavimą. Mano patirtis rodo, kad reikalingas pasaulinis kontekstas dažnai atsiranda dėl padidėjusio domeno žinių sudėtingumo. Nors galbūt norėsite išbandyti tik konkretų komponentą arba programos dalį, negalėsite to padaryti nepasidalinęs visuotinėmis priklausomybėmis, kurių reikia šiam segmentui.

Privalumai

Šio kūrinio rašymo metu pritaikyti įmonių taikomąsias programas buvo teisingas sprendimas dėl techninės priežiūros (nepaisant kritinio momento, kurį patyrė Facebook, kai pakeitė bibliotekos licencijavimo modelį). „ReactJs“ suteikia atgalinį nebenaudojamų API suderinamumą, todėl ilgalaikis pritaikymas yra vienas iš pagrindinių privalumų.

Kontekstai

Tarsi komponentų neužtenka kaip abstrakčios sąvokos, kontekstai taip pat yra vienas iš „reactjs“ pranašumų testuojant. Plačiau apie šią temą rašau tinklaraščio įraše, skirtame reactjs konteksto testavimui . Inkapsuliavimo lygis, kurį suteikia „Reactjs“ kontekstas, yra vienas iš pagrindinių privalumų modifikuojant testus ir įgalinant reactjs kodų bazes.

Kadangi komponentų išskaidymas ir verslo logika yra iššūkis, kontekstai yra įrankiai, leidžiantys geriau pertvarkyti kodą. Kalbant apie tikrinamumą, tai taip pat yra pranašumas, nes tai yra mechanizmas, leidžiantis sumažinti naudojamų testų dvigubų skaičių, todėl kodas yra labiau išbandomas.

Atnaujinimo bandymai

Turint omenyje tokį sąrašą iki šiol, tikimasi, kad testavimo dalis tapo aiški, kuri priklauso nuo šaltinio kodo struktūros ir nuo to, kaip buvo sutvarkytos programos ribos. Tačiau, kadangi testavimo kodas priklauso nuo gamybos kodo, testavimo dvigubai gali būti naudojami siekiant apriboti taikymo sritį. Bandymų modifikavimo procesas susideda iš kelių paprastų žingsnių.

1. Parašykite paprastą norimo funkcionalumo bandomąjį atvejį.
2. Paleiskite bandomąjį atvejį ir pamatysite, kad jis nepavyko.

2.1. Ar testas praėjo?

 2.1.1 - Yes → Check if the feedback is correct 2.1.2 - No → Provide the dependency without questioning

3. Grįžkite į 1.

Atkreipkite dėmesį, kad: čia aprašytas metodas yra panašus į tai, kas apibūdinama kaip charakterizavimo testas, aprašytas Michaelo Featherso.

Veiksmingas darbas su senojo kodo knyga.

LLM atsiradimas taip pat gali suteikti įžvalgų rašant pirmuosius testus ir modifikuojant kodų bazes be jokių testų. Kiekvienas šios strategijos žingsnis turi būti kartojamas; galima derinti ir skirtingus TDD stilius. Siūlomas požiūris yra nenustoti daryti visko ir modifikuoti visus įmanomus bandomuosius atvejus ir visas galimas kodo bazės problemas, tai yra galvosūkių žaidimas. Kiekvienas išbandytas funkcionalumas yra dalis, tinkanti dėlionei.

Tas pats metodas siūlomas ir pertvarkymui. Kūrėjai turėtų turėti galimybę nuolat pertvarkyti kodo dalį. Tai nėra kitoks projektas ir nesiekiama tik jam skirti. Pagrindinis jo tikslas yra padaryti kodo bazę geresnę nei buvo. Iteratyviai. Yra keli aspektai, kuriuos galima naudoti norint modifikuoti testus kodų bazėse, kurios jų neturi:

• Klaidos taisymas – tai galimybė susipažinti su kodu ir suprasti, kaip jis veikia. Klaidos taisymas yra problemos dalis, tačiau tai taip pat yra galimybė apibūdinti esamą programą.
• Naujos funkcijos įdiegimas – tai tas pats, kas klaidos taisymas, tačiau pasirinktas požiūris šiek tiek keičiasi. Tai tas pats požiūris, kurį pasiūlė Kentas Bekas: „Padarykite pakeitimą lengvą, tada padarykite lengvą pakeitimą“. Nauja funkcija yra vieta, kurioje pateikiama kodo bazė, skirta pakeitimui prieš pristatant naują funkciją.

Šio požiūrio esmė yra mokymosi procesas; atsižvelgiama į kiekvieną kodo bazės mokymosi žingsnį.

LLM

Copilot gali būti naudojamas automatizuoti pirmąjį tiriamąjį testą, aprašytą ankstesniame skyriuje; laikantis trijų taisyklių, galima pradėti nustatant priklausomybes ir parašant išsamių testų rinkinį, kuris bus naudojamas kaip pagrindas.

Paimkime Testable kaip pavyzdį; tai programa, kuri buvo parašyta daugiau nei prieš penkerius metus reactjs ir naudoja fermentą bandymams. Pagal šiandienos standartą biblioteka, kuri perėmė, yra „vitest“ arba „juoks“ kartu su testavimo biblioteka. Norėdami modifikuoti bandomuosius atvejus, kad būtų galima išbandyti, ir pasinaudoti LLM teikiamais privalumais, galime naudoti antrąjį pilotą, kad padėtų mums kelti sunkumus.

Testable sudaro žaidybinė patirtis, kurios būsena, lygiai ir vartotojo pažanga vykstant įvairiems iššūkiams. Šiame paveikslėlyje aprašytas komponentas yra komponentas, naudojamas dialogams rodyti ir naršyti pirmyn patirties istorijoje. Naudodamas Copilot for vscode, paprašiau parašyti testą su mus dominančiu gamybos kodu:

Kai jis įkelia klausimą ir išanalizuoja kodą, jis pateikia atsakymą.

Kartu su atsakymu Copilot pastebėjo, kad aš dar nenaudoju testavimo bibliotekos ir siūlo tai padaryti, o po to rodomas sugeneruotas bandomasis atvejis. Vykdant bandomąjį atvejį, kaip parodyta, testas nepraeina ir pažymimas kaip raudonas.

Šis punktas svarbus, nes parodo, kad reikia atsižvelgti į papildomą sąranką, o „Copilot“ negalėjo to išsiaiškinti. Jie yra tokie:

• Importas neteisingas; jį reikia pataisyti, kad būtų nurodytas tinkamas failas.
• Turinio sąranka neteisinga; failas negalėjo padaryti turinio tinkamu bandomajam atvejui.

Anksčiau šiame skyriuje aprašytas srautas galioja ir čia. Dabar grįžtamojo ryšio ciklas yra pradėti taisyti šias problemas ir vykdyti bandymus, kol bus baigtas TDD ciklas.

Ištekliai

• Charakteristikos testas