CSS võltsreegel: vastupidav testimine CSS-testide teisikutega

Cascading Style Sheets (CSS) testimine võib olla veebiarenduse keeruline, kuid samas oluline aspekt. Traditsioonilised testimismetoodikad maadlevad sageli CSS-koodi isoleerimise ja selle käitumise tõhusa kontrollimisega. Siin tuleb mängu "CSS võltsreegli" või täpsemalt CSS-testide teisikute kontseptsioon. See artikkel sukeldub CSS-i testimise maailma testide teisikuid kasutades, uurides nende eeliseid, rakendustehnikaid ja parimaid tavasid vastupidavate ja hooldatavate stiililehtede loomiseks erinevates brauserites ja seadmetes.

Mis on CSS-testide teisikud?

Tarkvaratestimises on testide teisik üldtermin mis tahes objekti kohta, mis testitava reaalse objekti asemel seisab. Testide teisikute kasutamise eesmärk on isoleerida testitav üksus ja kontrollida selle sõltuvusi, muutes testimise ettearvatavamaks ja keskendumisemaks. CSS-i kontekstis on testide teisik (mida me lihtsuse huvides nimetame "CSS võltsreegliks") tehnika kunstlike CSS-reeglite või käitumiste loomiseks, mis jäljendavad päris asja, võimaldades teil kontrollida, kas teie JavaScript või muu esiotsa kood interakteerub CSS-iga oodatud viisil, ilma et sõltuksite tegelikust renderdusmootorist või välistest stiililehtedest.

Sisuliselt on need simuleeritud CSS-käitumised, mis on loodud komponentide interaktsioonide testimiseks ja koodi isoleerimiseks testimise ajal. See lähenemisviis võimaldab keskendunud üksustestimist JavaScripti komponentidele või muule esiotsa koodile, mis sõltub konkreetsetest CSS-stiilidest või käitumistest.

Miks kasutada CSS-testide teisikuid?

CSS-testide teisikute lisamine teie testimisstrateegiasse pakub mitmeid olulisi eeliseid:

• Isolatsioon: Testide teisikud võimaldavad teil isoleerida testitavat koodi brauseri renderdusmootori ja väliste CSS-stiililehtede keerukusest. See muudab teie testid keskendumisemaks ja vähem vastuvõtlikuks välistest teguritest põhjustatud valepositiivsetele või valenegatiivsetele tulemustele.
• Kiirus: Testide käivitamine tõelise brauseri renderdamise vastu võib olla aeglane ja ressursimahukas. Testide teisikud, olles kerged simulatsioonid, kiirendavad oluliselt teie testikomplekti täitmist.
• Ettearvatavus: Brauserite ebajärjekindlus ja väliste stiililehtede muudatused võivad muuta testid ebausaldusväärseks. Testide teisikud pakuvad ühtlast ja ettearvatavat keskkonda, tagades, et teie testid ebaõnnestuvad ainult siis, kui testitaval koodil on viga.
• Kontroll: Testide teisikud võimaldavad teil kontrollida CSS-keskkonna olekut, muutes erinevate stsenaariumide ja piirjuhtumite testimise võimalikuks, mida võib reaalses brauserikeskkonnas olla raske või võimatu reprodutseerida.
• Varajane veatuvastus: CSS-i käitumist simuleerides saate varakult arendusprotsessis tuvastada oma esiotsa koodi interaktsiooniprobleeme CSS-iga. See hoiab ära vigade tootmisse sattumise ja vähendab silumisaega.

CSS-testide teisikute tüübid

Kuigi "CSS võltsreegli" mõistet kasutatakse laialdaselt, võib CSS-i testimisel kasutada erinevat tüüpi testide teisikuid:

• Stubid: Stubid pakuvad testide ajal tehtud päringutele etteantud vastuseid. CSS-i testimisel võib stub olla funktsioon, mis tagastab määratud CSS-i atribuudi väärtuse, kui seda kutsutakse. Näiteks võib stub tagastada väärtuse `20px`, kui seda küsitakse elemendi `margin-left` atribuudi kohta.
• Mockid: Mockid on stubidest keerukamad. Need võimaldavad teil kontrollida, kas konkreetseid meetodeid kutsuti konkreetsete argumentidega. CSS-i testimisel võib moci kasutada selleks, et kontrollida, kas JavaScripti funktsioon seab nupu klõpsamisel elemendi `display` atribuudi `none`-iks.
• Võltsingud: Võltsingud on töötavad implementatsioonid, kuid võtavad tavaliselt mõningaid otseteid, mis muudavad need tootmiseks sobimatuks. CSS-i testimisel võib see olla lihtsustatud CSS-i parsija, mis käsitleb ainult CSS-funktsioonide alamhulka, või tühi element, mis simuleerib CSS-i paigutuse käitumist.
• Nuhid: Nuhid salvestavad teavet selle kohta, kuidas funktsiooni või meetodit kutsutakse. CSS-i testimisel võib nuhi kasutada selle jälgimiseks, mitu korda konkreetset CSS-i atribuuti testide ajal kasutatakse või muudetakse.

Rakendustehnikad

CSS-testide teisikute rakendamiseks võib kasutada mitmeid tehnikaid, sõltuvalt teie testimisraamistikust ja testitava CSS-i keerukusest.

1. JavaScript-põhised moci

See lähenemisviis hõlmab JavaScripti moci-raamatukogude (nt Jest, Mocha, Sinon.JS) kasutamist CSS-iga seotud funktsioonide või meetodite vahelejätmiseks ja manipuleerimiseks. Näiteks saate moci-dada meetodit `getComputedStyle`, et tagastada etteantud CSS-i atribuudi väärtused. JavaScripti kood kasutab seda meetodit tavaliselt elemendi stiiliväärtuste hankimiseks pärast seda, kui brauser on stiilid rakendanud.

Näide (Jest kasutades):

const element = document.createElement('div'); const mockGetComputedStyle = jest.fn().mockReturnValue({ marginLeft: '20px', backgroundColor: 'red', }); global.getComputedStyle = mockGetComputedStyle; // Nüüd, kui JavaScripti kood kutsub getComputedStyle(element), saab see moci-dud väärtused. //Testi näide expect(getComputedStyle(element).marginLeft).toBe('20px'); expect(getComputedStyle(element).backgroundColor).toBe('red');

Selgitus:

• Loome moci-funktsiooni `mockGetComputedStyle`, kasutades `jest.fn()`.
• Kasutame `mockReturnValue`, et määrata väärtused, mida moci-funktsioon peaks kutsumisel tagastama. Sel juhul tagastab see objekti, mis jäljendab `getComputedStyle` tagastusväärtust, koos etteantud `marginLeft` ja `backgroundColor` atribuutidega.
• Asendame globaalse funktsiooni `getComputedStyle` meie moci-funktsiooniga. See tagab, et iga JavaScripti kood, mis kutsub testide ajal `getComputedStyle`, kutsub tegelikult meie moci-funktsiooni.
• Lõpuks väidame, et `getComputedStyle(element).marginLeft` ja `getComputedStyle(element).backgroundColor` kutsumine tagastab moci-dud väärtused.

2. CSS-i parsingu- ja manipuleerimisraamatukogud

Raamatukogusid nagu PostCSS või CSSOM saab kasutada CSS-stiililehtede parsingu-ks ja CSS-reeglite mälusisese esinduse loomiseks. Seejärel saate neid esindusi manipuleerida, et simuleerida erinevaid CSS-olekuid ja kontrollida, kas teie kood reageerib õigesti. See on eriti kasulik dünaamilise CSS-iga interaktsioonide testimiseks, kus stiile lisab või muudab JavaScript.

Näide (kontseptuaalne):

Kujutage ette, et testite komponenti, mis klõpsates nuppu vahetab elemendil CSS-klassi. Saate kasutada CSS-i parsingu-raamatukogu:

1. Teie komponendiga seotud CSS-stiililehe parsingu-ks.
2. Leidke reegel, mis vastab vahetatavale CSS-klassile.
3. Simuleerige selle klassi lisamist või eemaldamist, muutes stiililehe mälusisest esindust.
4. Kontrollige, kas teie komponendi käitumine muutub vastavalt simuleeritud CSS-olekule.

See väldib brauseri sõltuvust stiilide rakendamisest elemendile. See võimaldab palju kiiremat ja isoleeritud testi.

3. Shadow DOM ja isoleeritud stiilid

Shadow DOM pakub võimalust kapseldada CSS-stiile komponendi sees, takistades nende lekkimist ja mõjutamist teisi rakenduse osi. See võib olla abiks isoleeritumate ja ettearvatavamate testimiskeskkondade loomisel. Kui komponent on kapseldatud Shadow DOM-i abil, saate testides selle konkreetse komponendi jaoks kehtivaid CSS-stiile kergemini kontrollida.

4. CSS Modules ja Atomic CSS

CSS Modules ja Atomic CSS (tuntud ka kui funktsionaalne CSS) on CSS-arhitektuurid, mis soodustavad modulust ja korduvkasutamist. Need võivad ka lihtsustada CSS-i testimist, muutes konkreetset komponenti mõjutavate CSS-reeglite tuvastamise ja isoleerimise lihtsamaks. Näiteks Atomic CSS-is esindab iga klass ühte CSS-i atribuuti, nii et saate üksikute klasside käitumist hõlpsasti moci-dada või stub-ida.

Praktilised näited

Uurime mõningaid praktilisi näiteid selle kohta, kuidas CSS-testide teisikuid saab kasutada erinevates testimisstseenides.

Näide 1: Modaalikomponendi testimine

Mõelge modaalkomponendile, mida kuvatakse ekraanil, lisades selle konteinerelemendile klassi `show`. Klass `show` võib määratleda stiile, et paigutada modaal ekraani keskele ja muuta see nähtavaks.

Selle komponendi testimiseks saate moci-d kasutada, et simuleerida klassi `show` käitumist:

// Oletagem, et meil on funktsioon, mis vahetab modaalelemendil klassi "show" function toggleModal(modalElement) { modalElement.classList.toggle('show'); } // Test describe('Modaal komponent', () => { it('peaks kuvama modaali, kui lisatakse show-klass', () => { const modalElement = document.createElement('div'); modalElement.id = 'myModal'; // Mock getComputedStyle tagastama konkreetseid väärtusi, kui "show"-klass on olemas const mockGetComputedStyle = jest.fn((element) => { if (element.classList.contains('show')) { return { display: 'block', position: 'fixed', top: '50%', left: '50%', transform: 'translate(-50%, -50%)', }; } else { return { display: 'none', }; } }); global.getComputedStyle = mockGetComputedStyle; // Algselt peaks modaal olema peidetud expect(getComputedStyle(modalElement).display).toBe('none'); // Vaheta "show"-klassi toggleModal(modalElement); // Nüüd peaks modaal olema kuvatud expect(getComputedStyle(modalElement).display).toBe('block'); expect(getComputedStyle(modalElement).position).toBe('fixed'); expect(getComputedStyle(modalElement).top).toBe('50%'); expect(getComputedStyle(modalElement).left).toBe('50%'); expect(getComputedStyle(modalElement).transform).toBe('translate(-50%, -50%)'); }); });

Selgitus:

• Loome `getComputedStyle`-i moci-implementatsiooni, mis tagastab erinevaid väärtusi sõltuvalt sellest, kas `show`-klass on elemendil olemas või mitte.
• Vahetame modaalelemendi `show`-klassi, kasutades väljamõeldud funktsiooni `toggleModal`.
• Väidame, et modaali `display` atribuut muutub `none`-ilt `block`-iks, kui `show`-klass on lisatud. Samuti kontrollime paigutust, et tagada modaali õige tsentreerimine.

Näide 2: Responsiivse navigatsioonimenüü testimine

Mõelge responsiivsele navigatsioonimenüüle, mis muudab oma paigutust sõltuvalt ekraani suurusest. Võite kasutada meediapäringuid erinevate piiripunktide jaoks erinevate stiilide määratlemiseks. Näiteks mobiilne menüü võib olla peidetud hamburgerikooni taha ja kuvatakse ainult siis, kui ikooni klõpsatakse.

Selle komponendi testimiseks saate moci-d kasutada, et simuleerida erinevaid ekraani suurusi ja kontrollida, kas menüü käitub õigesti:

// Mock global.window.innerWidth atribuudi, et simuleerida erinevaid ekraani suurusi const mockWindowInnerWidth = (width) => { global.innerWidth = width; global.dispatchEvent(new Event('resize')); // Käivita suuruse muutmise sündmus }; describe('Responsiivne navigatsioonimenüü', () => { it('peaks kuvama mobiilse menüü, kui ekraani suurus on väike', () => { // Simuleeri väikest ekraani suurust mockWindowInnerWidth(600); const menuButton = document.createElement('button'); menuButton.id = 'menuButton'; document.body.appendChild(menuButton); const mobileMenu = document.createElement('div'); mobileMenu.id = 'mobileMenu'; document.body.appendChild(mobileMenu); const mockGetComputedStyle = jest.fn((element) => { if(element.id === 'mobileMenu'){ return { display: (global.innerWidth <= 768) ? 'block' : 'none' }; } else { return {}; } }); global.getComputedStyle = mockGetComputedStyle; // Väida, et mobiilne menüü on algselt kuvatud (oletades, et algne CSS seab selle üle 768px väärtusele none) expect(getComputedStyle(mobileMenu).display).toBe('block'); }); it('peaks peitma mobiilse menüü, kui ekraani suurus on suur', () => { // Simuleeri suurt ekraani suurust mockWindowInnerWidth(1200); const menuButton = document.createElement('button'); menuButton.id = 'menuButton'; document.body.appendChild(menuButton); const mobileMenu = document.createElement('div'); mobileMenu.id = 'mobileMenu'; document.body.appendChild(mobileMenu); const mockGetComputedStyle = jest.fn((element) => { if(element.id === 'mobileMenu'){ return { display: (global.innerWidth <= 768) ? 'block' : 'none' }; } else { return {}; } }); global.getComputedStyle = mockGetComputedStyle; // Väida, et mobiilne menüü on peidetud expect(getComputedStyle(mobileMenu).display).toBe('none'); }); });

Selgitus:

• Määratleme funktsiooni `mockWindowInnerWidth`, et simuleerida erinevaid ekraani suurusi, seadistades `window.innerWidth` atribuudi ja käivitades `resize` sündmuse.
• Igal testil simuleerime konkreetset ekraani suurust, kasutades `mockWindowInnerWidth`.
• Seejärel väidame, et menüü on kuvatud või peidetud vastavalt simuleeritud ekraani suurusele, kontrollides, kas meediapäringud töötavad õigesti.

Parimad tavad

CSS-testide teisikute tõhususe maksimeerimiseks kaaluge järgmisi parimaid tavasid:

• Keskenduge üksustestimisele: Kasutage CSS-testide teisikuid peamiselt üksustestimiseks, kus soovite isoleerida üksikud komponendid või funktsioonid ja kontrollida nende käitumist isoleeritult.
• Hoidke testid lühikesed ja keskendumishuvilised: Iga test peaks keskenduma komponendi käitumise ühele aspektile. Vältige ülemäära keerukate testide loomist, mis üritavad korraga liiga paljusid asju kontrollida.
• Kasutage kirjeldavaid testinimisid: Kasutage selgeid ja kirjeldavaid testinimisid, mis peegeldavad täpselt testi eesmärki. See muudab testi kontrollimise mõistmise lihtsamaks ja aitab silumisel.
• Hooldage testide teisikuid: Hoidke oma testide teisikud ajakohasena tegeliku CSS-koodiga. Kui muudate CSS-stiile, veenduge, et teie testide teisikud oleksid vastavalt värskendatud.
• Tasakaal lõpp-lõpuni testimisega: CSS-testide teisikud on väärtuslik tööriist, kuid neid ei tohiks kasutada isoleeritult. Täiendage oma üksusteste lõpp-lõpuni testidega, mis kontrollivad rakenduse üldist käitumist tõelises brauserikeskkonnas. Tööriistad nagu Cypress või Selenium võivad siin olla hindamatud.
• Kaaluge visuaalset regressioonitestimist: Visuaalse regressiooni testimise tööriistad saavad tuvastada soovimatuid visuaalseid muudatusi, mis on põhjustatud CSS-i muudatustest. Need tööriistad teevad teie rakenduse ekraanipiltidest ja võrdlevad neid aluspiltidega. Kui tuvastatakse visuaalne erinevus, hoiatab teid tööriist, võimaldades teil seda uurida ja kindlaks teha, kas muudatus on tahtlik või viga.

Õigete tööriistade valimine

CSS-testide teisikute rakendamiseks saab kasutada mitmeid testimisraamistikke ja raamatukogusid. Mõned populaarsed valikud on:

• Jest: Populaarne JavaScripti testimisraamistik koos sisseehitatud moci-võimalustega.
• Mocha: Paindlik JavaScripti testimisraamistik, mida saab kasutada erinevate väite- ja moci-tööriistadega.
• Sinon.JS: Iseseisev moci-raamatukogu, mida saab kasutada mis tahes JavaScripti testimisraamistikuga.
• PostCSS: Võimas CSS-i parsingu- ja teisendusvahend, mida saab kasutada teie testides CSS-stiililehtede manipuleerimiseks.
• CSSOM: JavaScripti raamatukogu CSS-i objektimudeli (CSSOM) esindustega töötamiseks CSS-stiililehtedest.
• Cypress: Lõpp-lõpuni testimise raamistik, mida saab kasutada teie rakenduse üldise visuaalse välimuse ja käitumise kontrollimiseks.
• Selenium: Populaarne brauseri automatiseerimise raamistik, mida kasutatakse sageli visuaalse regressiooni testimiseks.

Kokkuvõte

CSS-testide teisikud ehk nagu me neid selles juhendis nimetame "CSS võltsreeglid", on võimas tehnika teie stiililehtede kvaliteedi ja hooldatavuse parandamiseks. Pakkudes võimalust CSS-i käitumist testide ajal isoleerida ja kontrollida, võimaldavad CSS-testide teisikud teil kirjutada keskendumisväärivamaid, usaldusväärsemaid ja tõhusamaid teste. Olenemata sellest, kas loote väikest veebisaiti või suurt veebirakendust, võib CSS-testide teisikute lisamine teie testimisstrateegiasse parandada teie esiotsa koodi vastupidavust ja stabiilsust. Pidage meeles, et neid tuleks kasutada koos teiste testimismetoodikatega, nagu lõpp-lõpuni testimine ja visuaalne regressioonitestimine, et saavutada põhjalik testikate.

Selles artiklis kirjeldatud tehnikate ja parimate tavade omaksvõtmisega saate luua vastupidavama ja hooldatavama koodibaasi, tagades, et teie CSS-stiilid töötavad õigesti erinevates brauserites ja seadmetes ning et teie esiotsa kood interakteerub CSS-iga oodatud viisil. Kuna veebiarendus jätkuvalt areneb, muutub CSS-i testimine üha olulisemaks ja CSS-testide teisikute kunsti valdamine on väärtuslik oskus igale esiotsa arendajale.