Hur man skriver A/A-testning för feature flags med Cypress.io och Selenium

På Optimizely distribuerar vi en stor del av vår kod bakom feature flags eftersom det ger oss fördelarna med att förkorta vår lanseringscykel, utföra A/B-testning och distribuera kodändringar säkrare med utrullningar. Medan feature flags (aka feature toggles) har hjälpt oss att driva bättre produkter som levereras snabbare, tenderar de att vara mycket svåra att skriva automatiseringstester mot. Av naturen gör feature flags att din kodbas blir icke-deterministisk, vilket orsakar stor förödelse när du skriver automatiseringstester mot den.

En analogi som jag gillar att göra är att automatiseringstester kan ses som tåg och koden kan ses som spår. Automationstester är fantastiska när det gäller att validera att spåret är korrekt byggt eftersom tåget kan köra snabbt längs spåret och låta dig veta om allt är på plats på rätt sätt. Men när du testar mot en feature flags kan dina spår ändras baserat på logiken i din flagga, och ditt tåg kan spåra ur eftersom en del av det spår som det förväntar sig att köra på kanske inte längre är tillgängligt. Detta gör att dina automatiseringstester blir flackande och ger dig många falskt positiva signaler.

På grund av denna spänning mellan spår och tåg eller feature flag och automationstest, får jag ofta frågan från olika utvecklare och kunder: "Hur skapar man automationstester mot feature flags?"

Här på Optimizely använder våra utvecklingsteam en mängd olika strategier för att hjälpa vårt automatiseringsramverk att säkerställa att koden som testas är deterministisk. Vi skulle vilja dela med oss av några av dessa idag.

Villkor för målgrupp

Optimizely Full Stack låter dig skapa ett specifikt publikvillkor som din testkörare passerar in som säkerställer att testköraren antingen alltid kommer att bucketas i funktionen eller aldrig bucketas i funktionen.

En snabb anteckning om exemplet nedan. På Optimizely använder Automation Team Cypress.io och Selenium för att köra vår End to End Test och Regression Automation Test. Detta specifika exempel skrevs i Cypress.io. Vi gillar verkligen Cypress.io eftersom det är snabbt och enkelt att utveckla i, har skärmdumpar och inspelningar och erbjuder robust rapportering. Du hittar vår enkla app med exempel och vår kod för Cypress.io-automationstester här.

I vår exempelapp nedan har vi lagt till en Optimizely feature flag runt astronautbilden. När flaggan är PÅ kommer vi att se astronauten (Feature On), och när flaggan är AV kommer vi inte att se den (Feature Off).

Vi vill att Cypress.io ska bekräfta båda villkoren (Flag On/Flag OFF) och validera att bilden visas eller tas bort på rätt sätt.

I din Optimizely feature flag skapar vi ett publikvillkor som heter cypress. Vi vill utlösa det här villkoret så vi ställer in en matchning för alla strängar som är lika med "on".

I Cypress.io test runner skickar vi frågeparametern cypress=on och validerar att den nya funktionen är på.

it('Validate that the astro_boy feature is enabled', function () { // Besök app med publikens frågeparameter cy.visit('/?cypress=on') // Validera att funktionen är aktiverad cy.get('#astronaut') .should('exist') })

Detta gör att vår Cypress.io-testlöpare vet exakt vad den ska testa för och bekräfta det.

Som du kan se nedan kör Cypress.io-testköraren våra faktiska testfall i vår app, växlar mellan funktioner på och av och bekräftar att bilden visas/inte visas.

Funktionalitet för vitlista

Optimizely ger dig också kapacitet att vitlista din testkörare för ett funktionstest (ett funktionstest är ett experiment som du kan köra på en specifik feature flag). Skicka in ett användar-ID som din testkörare kommer att använda för att säkerställa att Cypress.io alltid visar den variation som du vill att den ska hävda mot. Obs: den här funktionen är endast tillgänglig för test av funktioner och inte för utrullningar. Du kan se hur du gör detta i Optimizely på skärmdumpen nedan.

Ställ in påtvingad variation

Optimizely använder också Selenium-test som körs på ett BDD-ramverk. För dessa tester använder vi möjligheten att ställa in en påtvingad variation direkt i SDK. Följande exempel är en Selenium-implementering som tvingar en variation och sedan validerar den funktionsvägen(Obs: Tvungen variation fungerar endast med test av funktion och inte utrullning av funktioner).

Nedan har vi ett exempel på Gherkin där vi vill att vår Selenium-testlöpare ska säkerställa att den variation vi testar alltid är create_flow-variationen (den variation vi vill testa) och inte slumpmässigt tilldelas till andra variationer.

Scenario: Skapa en AB-kampanj med målgruppsinriktning via förenklat skapandeflöde Med tanke på att jag öppnar en webbläsare som persona "V2User"Sedan tvingar jag användaren "$acc_id" till "create_flow" av experimentet "exp1"När jag besöker "/v2/projects"Då ska jag se "Experiments"

Vår faktiska Python-kod anropar SDK, skickar in nyckeln till experimentet, ID från testköraren och vilken variation vi vill testa.

assert fullstack.set_forced_variation( experiment_key, user_id, variation, datafile_key ), 'Misslyckades med att rensa set_forced_variation' # Dubbelkolla assert fullstack.get_variation(experiment_key, user_id, datafile_key) is None, 'Misslyckades med att rensa set forced variation'

Det här är bara några strategier som vårt automatiseringsteam på Optimizely använder vid test av funktioner och utrullning av funktioner för att säkerställa att vi testar ny kod på ett deterministiskt sätt.

Har du en fantastisk strategi som inte syns här? Eller har du några frågor om vad vi gör? Vi vill gärna höra mer från dig! Kontakta oss på quality@optimizely.com

Om du är intresserad av att komma igång med hantering av features flags och kontrollerade utrullningar, kolla in vår kostnadsfria flaggningsprodukt: Optimizely Rollouts.