Menținerea calității de la capăt la capăt cu testarea vizuală

Testarea este o parte critică a fluxului de lucru al oricărui dezvoltator. Ne ajută să ne asigurăm că proiectul nostru va menține un nivel ridicat de calitate, precum și să împiedicăm orice insecte deranjantă să iasă în sălbăticie.

Dar adesea testele automate pot fi dificil de gestionat. Între o cantitate nesfârșită de cod pentru a vă asigura că oferiți o acoperire completă și vă ocupați de natura fragilă a testelor front-end - unde o simplă schimbare a selectorului poate întrerupe complet un flux de lucru end-to-end - poate fi uneori să se simtă ca o problemă. luptă.

Adăugând teste vizuale automate , putem elimina acele teste neconforme, ridicând nivelul conductelor noastre de testare, oferind acea acoperire (și mai mult), profitând de comparațiile inteligente de imagini folosind capturi de ecran ale site-ului sau aplicației noastre.

Înainte de a ne aprofunda în testarea vizuală, să luăm un minut pentru a ne reîmprospăta cu privire la diferitele tipuri de testare automată și la modul în care acestea se potrivesc. Vom vorbi apoi despre ce este exact testarea vizuală și cum vă poate oferi un alt nivel de acoperire a testării pentru proiectul dvs.

O privire rapidă asupra unora dintre tipurile de testare automată

Testarea automată este o parte interesantă a ciclului de dezvoltare. Unii clienți sau părți interesate pot vedea în mod clar valoarea pe care o oferă, dar alții ar prefera orice timp de dezvoltare alocat dezvoltării pură a caracteristicilor.

Acest lucru poate fi uneori contraintuitiv, în cazul în care scopul testării automate este de a proteja afacerea sau de a împiedica echipa să fie nevoită să petreacă timp remediând erorile. Scrierea unor teste automate solide poate preveni pierderi financiare majore! În cele din urmă, este un risc pe care unii sunt mai dispuși să-l asume decât alții.

Din fericire, această valoare nu este întotdeauna greu de vândut și, atunci când ni se oferă timp să ne concentrăm pe teste automate de calitate, avem o varietate de opțiuni pentru a aborda aceste teste, cum ar fi testarea unitară, testarea de integrare, testarea de la capăt la capăt. testare și testare vizuală (care poate oferi, de asemenea, o acoperire extinsă pentru primele trei).

Când sunt aplicate cu punctele forte ale fiecărui tip de test, suntem capabili să petrecem mai mult timp scriind teste care ne pot ajuta efectiv să ne protejăm munca și să salvăm frustrarea clienților noștri.

Să aruncăm o privire la cum arată unele dintre aceste strategii de testare în practică.

Testarea unitară

Testarea unitară se concentrează pe testarea unor zone mai mici și concentrate ale unei aplicații . Doriți să testați că o funcție care calculează un total de comandă după promoții funcționează corect? Ați dori să scrieți un test unitar.

 function myBusinessLogic(pricePerItem, quantity, discount) { const subtotal = pricePerItem * quantity; return subtotal - ( discount * subtotal ); } expect(myBusinessLogic(2, 4, .1)).toEqual(7.2);

Partea grozavă a testelor unitare este că acestea sunt ieftine de scris și nu necesită mult timp pentru a rula. De aceea, veți vedea adesea companii care petrec mult timp construind o suită de teste unitare pentru a captura acele părți granulare ale unei aplicații.

Dar, din cauza acestor teste concentrate, este posibil ca testarea unitară să nu acopere modul în care acele piese diferite lucrează împreună, de unde începem să trecem la testarea integrării.

Testare de integrare

Scopul testării integrării este de a lua piesele și componentele mai mici ale unei aplicații și de a testa modul în care acestea funcționează împreună . Un exemplu comun ar putea fi modul în care o anumită parte a unei interfețe de utilizator răspunde la interacțiuni urmate de solicitări către un server sau o bază de date.

 cy.get('.add-to-cart').click(); cy.url().should('contain', 'cart'); cy.get('.cart li').contains('My Item');

Este posibil ca componenta dvs. mică a interfeței de utilizare să funcționeze de la sine conform așteptărilor. Evenimentele dvs. sintetice se pot declanșa corect pe o instanță onClick. Acest cod care înglobează solicitările dvs. API ar putea funcționa perfect cu unele date batjocorite. Dar s-ar putea să existe găuri între acele două piese care lucrează împreună pe care testele dvs. de unitate ar putea să nu le prindă.

Testele de integrare sunt o modalitate convingătoare de a vă testa aplicația, dar puteți face acest pas mai departe în timp ce căutați să testați „toate lucrurile”.

Testare end-to-end

Testarea end-to-end captează întreaga călătorie a utilizatorului de la capăt la capăt pentru un flux de lucru concentrat. De exemplu, dacă construiesc un magazin de comerț electronic, „calea fericită” (sau calea așteptată cu cea mai mică rezistență) ar fi găsirea unui produs, adăugarea acestuia într-un coș și plata pentru acele articole. Dacă scriu un test de la capăt la capăt, aș surprinde întregul proces, adică de la găsirea unui produs pe o pagină de listare de produse până la plata pentru acel articol.

 cy.visit('/products'); cy.get('.product a[href="/product/1234"]').click() cy.url().should('contain', 'product/1234'); ... cy.get('.order-button').click(); cy.url().should('contain', 'receipt'); cy.get('.receipt li').contains('My Item');

Partea bună a testării end-to-end este că este, în esență, un mare test de integrare. Capturați o mulțime de componente diferite ale aplicației, inclusiv modul în care funcționează UI, că API-urile răspund corect și că acele piese lucrează împreună.

Problema este că testarea end-to-end, și chiar testarea integrării, durează mai mult timp pentru scriere și, de asemenea, durează mult mai mult pentru a rula. Deci, cum putem să profităm de toate opțiunile noastre de testare și să punem împreună o suită de teste care să ofere o modalitate eficientă de acoperire a aplicației noastre?

Utilizarea diferitelor tipuri de testare

Există o varietate de mentalități care descriu, în general, câte teste de fiecare tip ar trebui să vă petreceți timp scriind.

Mike Cohn a venit cu conceptul „piramidei de testare” în cartea sa Succeeding with Agile .

El susține că ar trebui să scrieți mai multe teste unitare unde acestea sunt mai puțin costisitoare de scris și mai rapid de rulat. În timp ce diagrama sa originală etichetează diferitele teste puțin diferit, pe măsură ce te înclini mai mult spre testarea de tip integrare, acestea devin mai lente de rulat și mai scumpe de scris. Deși acele teste sunt valoroase, nu doriți să aveți atât de multe integrări sau teste end-to-end cât ați avea teste unitare.

A avea acest echilibru vă poate ajuta să vă concentrați pe captarea părților critice ale aplicației, cum ar fi logica de afaceri cu teste unitare și modul în care acestea funcționează împreună cu testele de integrare, dar Kent C. Dodds susține că tehnologia de testare a ajuns până la un punct în care nu există costuri mari mai lungi pentru scrierea testelor de integrare, care este locul în care intervine conceptul său de „trofeu de testare”.

În mediile moderne de dezvoltare, avem la dispoziție o mulțime de instrumente uimitoare, cum ar fi Cypress, Selenium și Playwright, fiecare care oferă dezvoltatorilor și inginerilor QA capacitatea de a scrie teste care interacționează ușor cu browsere precum Chrome și Firefox.

Cu Cypress, scrierea unui test care face clic pe un buton ar putea arăta la fel de simplu ca:

 cy.get('#my-button').click()

Este, probabil, la fel de simplu ca și testarea faptului că butonul funcționează cu evenimente sintetice, dacă nu mai simplu. Cea mai bună parte este că testezi cum funcționează de fapt acel buton într-un browser.

Indiferent de diagrama la care vă abonați, în cele din urmă obiectivul este să cântăriți diferitele opțiuni între cost și viteză pentru a determina cea mai potrivită aplicație particulară. Este important să nu atingeți doar 100% din raportul dvs. de acoperire, ci să vă asigurați că experiența pe care o oferiți vizitatorilor funcționează așa cum ar trebui.

Dar indiferent de amestecul de teste pe care îl rulați, acestor teste programatice care interacționează și testează doar DOM (Document Object Model) le lipsește o piesă mare a puzzle-ului: modul în care vizitatorii dvs. văd vizual aplicația respectivă.

Ce tipuri tradiționale de testare nu surprind

Pe măsură ce rulați unitatea, integrarea și testarea end-to-end pe aplicația dvs., toate au un lucru în comun. Toți testează codul.

Ceea ce vreau să spun prin asta este că nu testează ceea ce vede de fapt vizitatorul aplicației tale.

Dacă rulați o suită de teste de integrare și, ca exemplul nostru anterior, testând că cineva poate adăuga un produs într-un coș și să-l achiziționeze, la fiecare pas, găsiți un element în DOM prin cod și confirmați că a funcționat în același mod.

Acest lucru nu testează lucruri precum dacă textul de pe pagina dvs. este lizibil sau nu. A adăugat cineva o modificare CSS care a plutit accidental toate lucrurile spre stânga și le-a răsturnat cu susul în jos?

Aceste tipuri de bug-uri sunt denumite „bunuri vizuale”, în cazul în care s-ar putea să treacă toate testele cu brio, dar când cineva se uită cu adevărat la ele, nu este chiar corect sau mai rău, complet inutilizabil.

În mod realist, nu ne putem aștepta să oferim o acoperire 100% completă a fiecărui detaliu al unei interfețe cu utilizatorul prin testarea tradițională. Între numărul nesfârșit de stări ale aplicației și faptul că adăugăm mereu noi funcții, pur și simplu nu se extind.

Acesta este ceea ce ne conduce la titlul acestei povești: Testarea vizuală .

Ce este testarea vizuală?

Testarea vizuală captează rezultatul vizibil (ca o captură de ecran) a unei aplicații și o compară cu aceeași aplicație într-un alt moment în timp.

Acest lucru se întâmplă de obicei prin captarea mai întâi a unei capturi de ecran de referință sau a unei instanțe capturate anterior a aplicației cu rezultatele așteptate și comparând fiecare nou test cu acea linie de bază.

Dar pe măsură ce proiectul tău este dezvoltat, lucrurile se schimbă. Pe măsură ce trece timpul, acea linie de bază se va actualiza imediat odată cu cererea dvs., pe măsură ce aprobați noi diferențe vizuale ca modificări acceptate.

Tipuri de testare vizuală

Un lucru interesant despre testarea vizuală este că există diferite moduri de a gestiona acest lucru.

O abordare a testării vizuale este utilizarea comparațiilor pixel cu pixel în care cadrul de testare va semnala literalmente orice diferență pe care o vede între două imagini. În timp ce astfel de comparații oferă un nivel de intrare în testarea vizuală, tinde să fie neconformat și poate duce la o mulțime de rezultate fals pozitive.

După cum vă puteți imagina, atunci când lucrați cu web, lucrurile tind să fie ușor diferit între încărcările paginilor și actualizările browserului. Dacă browserul redă pagina cu 1 pixel din cauza unei modificări de redare, a cursorului text afișat sau „doar pentru că”, implementările dvs. pot fi blocate din cauza acestor teste eșuate.

Testele dvs. sunt, de asemenea, predispuse la eșecuri atunci când aveți de-a face cu conținut dinamic. De exemplu, dacă ați rulat zilnic teste vizuale pixel cu pixel pe pagina de pornire a acestui site, Smashing Magazine , veți primi o mulțime de teste nereușite, deoarece produc din ce în ce mai mult conținut.

O modalitate mai bună de a gestiona testarea vizuală este prin folosirea tehnologiei precum AI, în care de fiecare dată când se rulează un test, cadrul de testare analizează în mod inteligent captura de ecran capturată în comparație cu linia de bază.

Poate detecta că cele două capturi sunt diferite sau chiar poate detecta dacă este o modificare de conținut, spre deosebire de o modificare a aspectului. Nu va semnala acel test ca eșuat dacă ceva nu s-a schimbat de fapt și puteți chiar adăuga reguli pentru a ignora regiunile dinamice ale unei aplicații care s-ar putea schimba din cauza acelui conținut.

Unde vă ajută testarea vizuală

Testarea vizuală prosperă în a putea surprinde starea actuală a unei aplicații așa cum a văzut-o clientul dvs. Acest lucru îl face convingător pentru orice aplicație care va avea oameni reali care interacționează cu ea.

Pe măsură ce captează acel instantaneu, oferă acoperire pentru multe părți ale acelei aplicații, nu doar o singură componentă granulară pentru care ați scris un test. Sfârșește prin a capta contextul din jurul acelei componente, ceea ce duce la o acoperire mai largă.

Aceasta devine o modalitate excelentă de a oferi o acoperire largă cu un cost redus . Revenind la piramida de testare sau la trofeul de testare, suntem capabili să oferim de fapt o acoperire cuprinzătoare pe lângă toate celelalte teste ale noastre.

Cum funcționează testarea vizuală?

Esența este simplă - comparând două imagini una față de alta și căutând diferența - dar este puțin mai implicat decât atât.

Comparații de imagini

La implementarea testării vizuale, scopul va fi să ofere acoperire pentru fluxurile de lucru critice care pot surprinde modul în care o persoană reală folosește aplicația. Acesta include adesea primul ecran pe care cineva îl vede, dar acesta nu este, de obicei, singurul ecran pe care îl vede.

La fel ca în crearea unei strategii pentru modul de rulare a testelor tradiționale, doriți să vă asigurați că căutați interacțiuni reale care se termină cu rezultate reale în interfața de utilizare, cum ar fi adăugarea unui articol într-un coș de cumpărături sau adăugarea unui articol preferat la lista de dorințe.

Având în vedere acest lucru, veți dori să faceți o captură de ecran la fiecare pas. De exemplu, dacă testați un magazin online, vă recomandăm să adăugați pași pentru următoarele:

• Lista de produse încărcate pe o pagină;
• Pagina produsului după selectarea unui singur produs;
• Interfața de utilizare a coșului de pe pagină după adăugarea unui produs la acel coș;
• Pagina coș după navigarea la coș;
• UI de plată și de expediere odată ce ați intrat în fluxul de plată;
• Pagina de chitanță la achiziție cu succes.

Acest lucru va surprinde rezultatele tuturor interacțiunilor pe măsură ce cineva își croiește drum prin magazinul dvs. online, unde puteți verifica că nu numai că funcționează funcțional din perspectiva codului, ci și că persoana poate folosi aplicația dvs. fără bug-uri vizuale care interferează.

Biți tehnice

Pe măsură ce vă faceți drum prin planificarea capturilor de ecran, veți avea nevoie de un mecanism pentru a automatiza aceste sarcini. Ceva care poate interacționa cu un browser bazat pe un set de sarcini.

Aici intervin cadrele populare de automatizare a browserului, cum ar fi Selenium, Cypress și Playwright, unde acele cadre de testare profită de API-urile browserului pentru a rula comenzile dvs., găsind și făcând clic pe lucruri exact ca un om, unde ați spune apoi cadrului de testare vizuală. când să capteze vizual starea UI.

În cazul Cypress și Applitools, Cypress ar naviga prin fiecare pagină, unde apoi SDK-ul Applitools ar extrage un instantaneu al DOM-ului și ar trimite acel instantaneu în cloud-ul Applitools, unde ar genera în cele din urmă capturi de ecran pentru comparație.

În acel moment, în funcție de platforma de testare vizuală, veți obține un set de rezultate sub formă de diferențe evidențiate sau un semn verde frumos dacă lucrurile arată bine.

Integrarea cu cadrele de testare existente

La fel ca integrarea Cypress și Applitools de mai sus, integrarea are de obicei o frecare scăzută. Multe dintre platformele de testare vizuală disponibile se pot integra direct în cadrele de testare existente, în mare parte depinde doar de SDK-urile pe care le au disponibile.

 cy.visit('/product/1234'); cy.eyesOpen({ appName: 'Online Store', testName: 'Product Page' }); cy.eyesCheckWindow(); cy.eyesClose();

Aceasta înseamnă că de obicei nu trebuie să rescrieți complet suita de teste pentru a vă consolida testele și pentru a obține acoperire vizuală; puteți adăuga acele puncte de control la testele pe care le aveți deja.

Automatizarea Testelor

Din fericire, automatizarea dezvoltării și a sarcinilor legate de testare s-a maturizat rapid, oferind o mulțime de opțiuni excelente pentru modul în care ne putem automatiza testele.

Soluțiile tradiționale CI/CD, cum ar fi Jenkins sau Travis CI, vă permit să vă rulați testele pe mediile lor chiar alături de restul procesului de integrare și implementare. Relativ noi pentru spațiul de automatizare sunt instrumente precum GitHub Actions, unde oferă un mecanism similar cu mediile tradiționale CI/CD, dar chiar în interiorul depozitului tău GitHub existent. Acest lucru face ca acesta să fie ușor de câștigat atunci când încercați să rulați automat testele și alte sarcini de cod, unde nu aveți nevoie de un sistem complet nou, ci folosiți instrumentele existente.

 name: Node.js CI on: [push, pull_request] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 12.x - run: npm ci - run: npm test

Dar, indiferent de mediul pe care îl utilizați, în cele din urmă sunteți supus cerințelor cadrului de testare. Cypress funcționează destul de perfect oriunde puteți instala Node.js, ceea ce este destul de comun în zilele noastre, atâta timp cât aveți acces la un browser fără cap precum Electron sau Chrome. Alții ar putea necesita puțin mediu suplimentar, dar în acel moment, de obicei, puteți schelete acel mediu după cum doriți, creând condițiile de care aveți nevoie pentru a vă rula testele.

Care sunt beneficiile testării vizuale?

Testarea vizuală va oferi o mare varietate de beneficii, cum ar fi unele dintre cele pe care le-am discutat deja, dar ajută cu adevărat toate părțile interesate, inclusiv directori, manageri de produs, dezvoltatori, designeri și cu adevărat pe oricine altcineva din echipă.

De exemplu, pentru un CEO sau un manager de produs, câștigați încredere că acoperirea dvs. de testare înregistrează de fapt utilizarea în lumea reală . Pentru echipa de dezvoltare, câștigați aceeași încredere că ori de câte ori faceți modificări, veți primi feedback imediat, eliminând factorul de frică implicat atunci când încercați să vă mișcați rapid. Dar există și o mulțime de beneficii practice.

Mai puțin cod de întreținut

Când vă integrați cu o platformă de testare vizuală, cea mai mare parte a codului dvs. se va învârti în jurul a două lucruri: interacțiuni și capturi de ecran.

Interacțiunile sunt în esență navigarea printr-o aplicație, găsirea paginii sau a fluxului de utilizatori pe care doriți să le capturați. Indiferent de modul în care testați, probabil că va trebui să mențineți acest lucru într-o formă sau alta.

Capturile de ecran, pe de altă parte, vor acoperi toate afirmațiile pe care le-ați scrie în mod normal într-un test. Comparând fiecare captură de ecran cu o linie de referință, vă asigurați automat că fiecare componentă a proiectului funcționează exact așa cum este prevăzut.

Testele sunt mai puțin fragile

Și folosind acele capturi de ecran ca mecanism de afirmare, testele tale vor fi mai puțin fragile și mai puțin fragile.

Dacă scrieți o afirmație împotriva unei anumite părți a DOM, cum ar fi folosirea unui ID sau a unui selector generat automat, riscați să faceți un test de rupere cu orice modificare a acelei componente.

Cu un ID, cineva ar putea pur și simplu să îl elimine sau să îl schimbe accidental. Poate ai crezut că este doar în scopuri funcționale și l-ai actualizat când ai reluat lucrurile, ceea ce a ajuns să rupă testul (mi s-a întâmplat!).

Sau dacă utilizați selectoare generale, indiferent dacă sunt generate automat sau nu, acestea tind să fie foarte specifice, deoarece testați părți foarte specifice ale aplicației . Dacă ajungeți să înghesuiți ceva HTML sau să mutați puțin lucrurile în cod, chiar dacă nu ați schimbat modul în care arată vizual, ar putea ajunge să întrerupă acel test.

Testează ce folosesc oamenii de fapt

Vorbind despre testarea modului în care arată vizual, atunci când testați vizual, testați ceea ce văd de fapt vizitatorii sau clienții dvs.

Folosirea HTML semantic adecvat nu face ca proiectul dvs. să fie utilizabil. O mică modificare CSS (cum ar fi z-index) poate schimba complet gradul de utilizare și modul în care arată ceva.

Prin capturarea unei capturi de ecran și comparând starea reală a aplicației prin interacțiunile fluxului unui utilizator, vă puteți asigura că aplicația dvs. funcționează atât funcțional, cât și că este utilizabilă de mai mult decât roboți de automatizare.

Lectură recomandată : Gestionarea CSS Z-Index în proiecte mari

Testează lucruri pe care nu te gândeai să le testezi

Obțineți, de asemenea, acoperire pentru diferite părți ale aplicației dvs. pe care nici nu v-ați gândit să le testați.

Luați în considerare lista de teste pe care le aveți în suita dvs., acestea sunt cele pe care v-ați gândit să le scrieți sau să le scrieți pentru că ați lovit anterior un bug. Dar restul aplicației?

Acea captură de ecran va surprinde mai multe detalii și context pe care celelalte teste ar putea să nu le fi inclus.

Ce nu acoperă testarea vizuală?

Dar testarea vizuală nu este destinată să fie o soluție finală pentru a înlocui întreaga suită de teste. La fel ca și celelalte tipuri de teste, ar trebui să coexiste, completând golurile celorlalte și, în cele din urmă, oferind o acoperire mai semnificativă.

Testarea logicii de afaceri bazate pe date

Pe măsură ce parcurgeți teste vizuale, este posibil să puteți surprinde unele aspecte ale logicii dvs. de afaceri, cum ar fi să vă asigurați că atunci când cineva adaugă un articol în coș, că matematica se verifică, dar magazinul dvs. online are probabil o varietate mai mare decât doar acel singur produs.

Este încă important să captați acea logică complexă de afaceri cu teste unitare, asigurându-vă că capturați diferite cazuri de utilizare, cum ar fi modul în care diferitele reduceri influențează acest total.

Testare API cuprinzătoare

Când aveți de-a face cu API-uri, vă puteți gândi la un test vizual ca un test de integrare. Putem testa că atunci când interacționăm cu browserul, logica noastră de solicitare funcționează conform așteptărilor. Dar nu oferă o privire cuprinzătoare asupra modului în care funcționează acel API.

Similar cu logica de afaceri, API-ul dvs. ar trebui să fie în continuare susținut de o suită de teste care să asigure că funcționează conform așteptărilor, cum ar fi teste unitare sau verificări de sănătate.

Noțiuni introductive cu testarea vizuală

Fiind un alt instrument din centura noastră, testarea vizuală poate ajuta cu adevărat să oferim un alt nivel de acoperire care ne ajută să menținem un nivel ridicat de calitate pentru aplicațiile noastre, dar de unde începem?

Încadrarea în ciclul de viață al dezvoltării

Deoarece testarea vizuală ajută la îndeplinirea obiectivelor tuturor părților interesate, aceasta se poate integra cu adevărat în orice parte a ciclului de viață al dezvoltării.

De exemplu, în mod tradițional, testele sunt folosite doar pentru a valida dacă codul funcționează conform intenției, dar putem folosi și testarea vizuală pentru transferul de proiectare și colaborarea UX . Designerii din echipă își pot conecta machetele ca bază și le pot folosi cu ușurință pentru a compara experiența reală.

Dar din perspectiva codului, testarea vizuală poate prospera în medii automate, cum ar fi efectuarea de verificări ale solicitărilor de extragere, medii de pregătire înainte de implementare și asigurarea faptului că producția arată bine după implementare.

Puteți chiar să vă rulați testarea vizuală pe un cron, înlocuind evenimentele sintetice de verificare a stării de sănătate, care de obicei sunt nesigure și nu vă spun niciodată cu adevărat în ce stare se află aplicația dvs.

Din fericire, există o mulțime de opțiuni atât pentru serviciul pe care îl utilizați, cât și pentru punctele de integrare pentru utilizarea acelor servicii.

Soluții disponibile pentru testarea vizuală

Determinarea cu ce soluție să mergeți mai departe se bazează pe alegerea bibliotecii sau a serviciului pe care îl veți folosi pentru a rula testele. Așa cum am menționat mai devreme, cel mai mare diferențiere va fi tipul de testare vizuală pe care aceste servicii îl oferă.

Multe platforme folosesc testarea vizuală pixel cu pixel pentru a efectua verificări. Aceasta include instrumente precum Percy și Chromatic, care vor semnala modificările între două capturi de ecran.

Apoi aveți teste vizuale bazate pe inteligență artificială, unde Applitools este cu adevărat singurul serviciu care oferă în prezent această capacitate. În loc să verifice pur și simplu imaginile pixel-cu-pixel, Applitools compară inteligent imaginile evitând orice teste necompletate sau fals pozitive , oferind o detectare semnificativă a schimbărilor.

Indiferent de soluție, în cele din urmă va trebui să o integrați în mediul dvs. de dezvoltare, indiferent dacă începeți de la zero sau o adăugați la un cadru de testare existent.

Integrarea testării vizuale

Atunci când integrați platforma de testare vizuală dorită, aveți opțiunea de a începe de la zero sau calea mai ușoară de integrare în cadrul de testare existent. Instrumente precum Applitools facilitează acest lucru, unde marea varietate de SDK-uri acceptate facilitează introducerea în fluxurile de lucru existente.

Un bun exemplu în acest sens este dacă sunteți deja configurat și rulați cu Cypress:

 it('should log into the application', () => { cy.get('#username').type('colbyfayock'); cy.get('#password').type('Password1234'); cy.get('#log-in').click(); cy.get('h1').contains('Dashboard'); });

Dacă efectuați deja teste programatice, puteți pur și simplu să stratificați testarea vizuală pentru a oferi un alt nivel de acoperire.

 it('should log into the application', () => { cy.eyesOpen({ appName: 'My App', testName: 'Login' }); cy.get('#username').type('colbyfayock'); cy.get('#password').type('Password1234'); cy.get('#log-in').click(); cy.eyesCheckWindow(); cy.eyesClose(); });

Și unele SDK-uri fac și mai ușor, în cazul în care, dacă rulați deja o bibliotecă Storybook, tot ce trebuie să faceți este să instalați pachetul cu npm și să rulați o comandă simplă, atunci aveți o acoperire completă a tuturor componentelor dvs.

 npm install @applitools/eyes-storybook --save-dev npx eyes-storybook

În cele din urmă, cea mai mare întrebare este ce cadru de testare veți dori să utilizați și dacă serviciul pe care doriți să îl utilizați acceptă acel cadru.

Utilizări creative ale testării vizuale

Pe lângă obținerea unui alt nivel de acoperire a testării pentru aplicația dvs., există o varietate de alte moduri prin care puteți profita de testarea vizuală.

• Monitorizarea timpului de funcționare
  Rulați în mod regulat un test vizual semnificativ în loc de monitorizarea tipică a timpului de funcționare cu evenimente sintetice fragile.
• Colaborare design/UX
  De la transfer la problemele de utilizare, utilizați testarea vizuală pentru a oferi întregii echipe un mediu de colaborare.
• Testare de accesibilitate
  Captați probleme cheie care pot limita accesibilitatea aplicației dvs.
• Instantanee istorice
  Rularea periodică a unui test vizual vă poate ajuta să capturați instantanee, oferindu-vă cu ușurință o modalitate de a face referire la o stare mai veche a proiectului.
• Testare de localizare
  Cu testarea vizuală bazată pe inteligență artificială care poate detecta modificările de conținut, aveți capacitatea de a vă asigura că totul arată și funcționează conform așteptărilor, indiferent de limbă. Bonus: puteți reduce cheltuielile generale atunci când încercați să comparați diferite versiuni ale unei anumite limbi.

Adăugând elementul vizual la testele dvs., obțineți mai multe opțiuni pentru a adăuga modalități semnificative de a menține un nivel ridicat de calitate pentru aplicația dvs.