Hvordan skrive automatiserte tester for funksjonsflagg med Cypress.io og Selenium

Hos Optimizely distribuerer vi en stor del av koden vår bak funksjonsflagg fordi det gir oss fordelene med å forkorte utgivelsessyklusen, utføre A/B-tester og distribuere kodeendringer på en tryggere måte ved utrullinger. Selv om funksjonsflagg (også kjent som feature toggles) har hjulpet oss med å skape bedre produkter som leveres raskere, er de ofte svært vanskelige å skrive automatiserte tester mot. Det ligger i sakens natur at funksjonsflagging gjør kodebasen din ikke-deterministisk, noe som skaper store problemer når du skriver automatiseringstester mot den.

En analogi jeg liker å bruke, er at automatiseringstester kan sees på som tog, og koden kan ses på som skinner. Automatiseringstester er fantastiske til å validere at sporet er bygget riktig, fordi toget kan kjøre raskt nedover sporet og fortelle deg om alt er på plass som det skal. Når du tester mot et funksjonsflagg, kan det imidlertid hende at sporene endres basert på logikken i flagget, og toget kan spore av fordi en del av sporet som det forventer å kjøre på, kanskje ikke lenger er tilgjengelig. Dette fører til at testene dine blir ustabile og gir deg mange falske positive signaler.

På grunn av denne spenningen mellom spor og tog eller funksjonsflagg og automatiseringstest, får jeg ofte spørsmålet fra forskjellige utviklere og kunder: "Hvordan lager du automatiseringstester mot funksjonsflagg?"

Her i Optimizely bruker utviklingsteamene våre en rekke ulike strategier for å hjelpe automatiseringsrammeverket vårt med å sikre at koden det tester, er deterministisk. Vi vil gjerne dele noen av disse med deg i dag.

Publikumsbetingelser

Optimizely Full Stack lar deg opprette en spesifikk målgruppe som testløperen din passerer inn i, og som sikrer at testløperen enten alltid blir bucketet i funksjonen eller aldri blir bucketet i funksjonen.

En rask bemerkning om eksemplet nedenfor. Hos Optimizely bruker automatiseringsteamet Cypress.io og Selenium til å kjøre vår End to End Test og Regression Automation Test. Dette spesifikke eksemplet ble skrevet i Cypress.io. Vi liker Cypress.io fordi det er raskt og enkelt å utvikle i, har skjermbilder og opptak, og tilbyr robust rapportering. Du finner vår enkle eksempelapp og koden for Cypress.io automatiseringstester her.

I eksempelappen vår nedenfor har vi lagt til et Optimizely-funksjonsflagg rundt astronautbildet. Når flagget er PÅ, vil vi se astronauten (Feature On), og når flagget er AV, vil vi ikke se astronauten (Feature Off).

Vi vil at Cypress.io skal bekrefte begge tilstandene (Flagg på/Flagg av) og validere at bildet vises eller fjernes på riktig måte.

I Optimizely-funksjonsflagget ditt oppretter vi en publikumsbetingelse kalt cypress. Vi ønsker å utløse denne betingelsen, så vi setter en match for alle strenger som er lik "on".

I Cypress.io test runner, sender vi spørringsparameteren cypress=on og validerer at den nye funksjonen er på.

it('Validate that the astro_boy feature is enabled', function () { // Besøk app med spørringsparameter for publikum cy.visit('/?cypress=on') // Valider at funksjonen er aktivert cy.get('#astronaut') .should('exist') })

Dette gjør at Cypress.io-testløperen vår vet nøyaktig hva den skal teste for, og kan teste på det.

Som du kan se nedenfor, utfører Cypress.io-testløperen våre faktiske testtilfeller i appen vår, veksler mellom funksjoner på og av, og bekrefter at bildet vises/ikke vises.

Funksjonalitet for hviteliste

Optimizely gir deg også muligheten til å hviteliste testløperen din for en funksjonstest (en funksjonstest er et eksperiment du kan kjøre på et spesifikt funksjonsflagg). Legg inn en bruker-ID som testløperen din skal bruke for å sikre at Cypress.io alltid ser den varianten du vil at den skal teste mot. Merk: Denne funksjonaliteten er bare tilgjengelig for Feature Test og ikke for Rollouts. Du kan se hvordan du gjør dette i Optimizely i skjermbildet nedenfor.

Angi tvungen variasjon

Optimizely bruker også Selenium-tester som kjøres på et BDD-rammeverk. For disse testene bruker vi muligheten til å angi en tvungen variasjon direkte i SDK-en. Følgende eksempel er en Selenium-implementering som tvinger frem en variasjon og deretter validerer den funksjonsbanen(Merk: Tvungen variasjon fungerer bare med Feature Test og ikke Feature Rollouts).

Nedenfor har vi et eksempel på en Gherkin der vi ønsker at Selenium-testløperen vår skal sikre at variasjonen vi tester alltid er variasjonen create_flow (variasjonen vi ønsker å teste) og ikke tilfeldig blir tilordnet andre variasjoner.

Scenario: Opprett en AB-kampanje med url-målretting via forenklet opprettingsflytGitt at jeg åpner en nettleser som persona "V2User"Deretter tvinger jeg bucket-brukeren "$acc_id" inn i "create_flow" i eksperimentet "exp1"Når jeg besøker "/v2/projects ", skal jeg se "Experiments"

Vår faktiske Python-kode kaller til SDK, sender inn nøkkelen til eksperimentet, ID-en fra testløperen og hvilken variant vi ønsker å teste.

assert fullstack.set_forced_variation( experiment_key, user_id, variation, datafile_key ), 'Failed to clear set_forced_variation' # Dobbeltsjekk assert fullstack.get_variation(experiment_key, user_id, datafile_key) is None, 'Failed to clear set forced variation'

Dette er bare noen av strategiene automatiseringsteamet vårt hos Optimizely bruker når vi tester og lanserer nye funksjoner for å sikre at vi tester ny kode på en deterministisk måte.

Har du en fantastisk strategi som ikke er nevnt her? Eller har du noen spørsmål om hva vi gjør? Vi vil gjerne høre mer fra deg! Kontakt oss på quality@optimizely.com

Hvis du er interessert i å komme i gang med flagging av funksjoner og kontrollerte utrullinger, kan du ta en titt på vårt gratis flaggingsprodukt: Optimizely Rollouts.