Morn
Morn!
Morn!
God morgen! Jeg driver stadig vekk og jobber meg gjennom 7 GUIS. I dagens video skriver jeg noen ganske kule tester, inspirert av ting vi har gjort på jobb: Testene interagerer med UI-et og klarer å fange opp at feks å klikke på en knapp får UI-et i rett tilstand. Men det er fortsatt bare data og lynraske tester. Som vi snakket om på lunsj @msolli @emil0r 😊 https://youtu.be/fcwyUIAv87E
Veldig interessant! Jeg er nysgjerrig på hvilken strategi med du ville tatt for oppsett av testene dersom action'ene hadde kall til server også, hvor flyten styres av dataene/resultatet fra serveren.
(vi har mange slike tester i vårt opplegg, og akkurat det med api-kall er litt clunky i oppsett)
Som regel har jeg pleid å overstyre den aktuelle actionen for testene til å simulere resultatet, om du skjønner. Det blir veldig som en mock da, med de tradeoff-ene de har med seg.
jepp, det er det jeg også gjør
Jeg tror den eneste actionen vi har som går til serveren er kommandoer, så vi har litt test-kode for å simulere resultatet av kommandoer.
Men en kommando kan føre til at det kommer nye data over websocketen, og det får vi ikke testa uten å basically etterape flyten ved å manuelt sende inn dataene i pass 2.
MEN, vi har et opplegg for å kjøre data requestene til serveren i frontend-bygget vårt 😅 Vi bruker ikke det så mye til tester, det ble laget for Portfolio-oppsettet vårt.
> og det får vi ikke testa uten å basically etterape flyten ved å manuelt sende inn dataene i pass 2 Ja, det må vel nødvendigvis være slik. Jeg tenker allikevel at det er en styrke å ha fire-and-forget commands, og så reagere på data som kommer tilbake på et annet tidspunkt - på en rent idempotent måte.
(les: jeg vil gjerne ha commands i systemet mitt, istedenfor haugevis med rest'ish apier)
Ja, helt klart! Du slipper liksom "kartesisk produkt av actions" som testflate