91. 1000 rader
lyssna! 
Vi inleder med glögg och födelsedagar innan vi pratar om ett enda ensamt end-2-end-test. Det blir allt om stora och små tester, att inte mocka saker, happy path, 6 månader senare, att “skuggprogrammera”, lite hat mot configfiler och att inte städa upp efter sig själv. Dessutom en hel del om happy path, mittemellan unit och e2e, en kanske upprepad anekdot om att DDOSa sig själv och mycket mycket annat.
Om du gillar podden blir vi väldigt glada för en liten recension i iTunes eller en prenumeration på Spotify. Följ oss och säg hej på @asdfpodden på Instagram eller Twitter (Anton, Therése) <3
Länkar
Avsnittets skämt:
Varför vill stallägare anställa mockare?
För att de är bra på att mocka.
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att klicka precis här :) Varför vill stallägare anställa testare?
För de mockar.
Jajamän, slasch egentligen för de är bra på att mocka.
Men det flög ändå.
Ja men det här skämtet har ju jag typ redan dragit.
Nej det tror jag inte.
Jo.
Och om det är så, då har alla glömt bort dig, fytan du.
Det är också ett skämt från vår lyssnare Erik, så tack Erik.
Och sen Therese direkt bashar, han har snott skämtet av mig.
Nej jag bara säger att du borde ha bättre koll på våra skämt.
Ja, ja, ja.
Allt är på dig, ingenting på lyssnarna.
Nej, så är det alltid.
Välkomna hörni till ett nytt avsnitt av AFSDF.
Jag ber om ursäkt om det klirrar litegrann, jag vet inte om det här hörs.
Hör du det här Therese?
Ja.
Ja det är ett härligt klirr, för jag har liksom unnat mig årets första glögg.
Kyld också, men stor isbit i.
Alltså nu vet ju jag att det säkert finns någon som blir upprörd för att det inte är december än.
Ja men det är på gränsen.
Och när det här avsnittet släpps så fyller jag år, och som den, som vi pratade om för några avsnitten,
narcissist jag är, så tar jag upp det själv.
Just det, för att det släpps verkligen på din kalsdag.
Så är det.
Och då kan man unna sig en inspelningsglögg, jag vet inte vilka glögg.
Woho!
Nej jag har inga planer, det ska bli jävligt skönt att bara ta det lugnt.
Jag ska väl fira att det här avsnittet har släppts. Det är större än att jag fyller år.
Wow.
Jajamän.
Var det så att det släpptes ett avsnitt på min födelsedag förra året?
Nej, jag minns faktiskt inte.
Ingen aning, det kan vi kolla upp till nästa avsnitt.
Verkligen inte viktigt, det är bara för att det är på julafton, så det är snarare frågan, släppte vi ett avsnitt på julafton?
Nej, vi släppte vår julkalender, ett avsnitt på julafton.
Ja, just det.
Och den kan vi avslöja nu en vecka innan, att julkalendern återkommer i år igen.
Bättre än någonsin.
Hahaha, okej.
Det är så skönt att i energinivå så tror jag att du är våra lyssnare, och jag är fonden.
Jag hajpar vår julkalender och de säger, okej.
Men alltså, okej, vill du att jag ska hajpa mer? Du vet ju att jag inte är den personen.
Nej, därför kan vi verkligen lägga det bakom oss och gå in på dagens ämne som jag har funderat på lite grann.
Senast tre dagar, kanske till och med tre och en halv, har jag skrivit ett test.
Och det här testet klockade in på 1015 rader när jag då merjade det idag.
Och det kändes väldigt härligt faktiskt.
Nej, nej men usch. Varför då? Varför då?
Jo, men det är ett test som gör väldigt mycket. Och då blev det väldigt långt.
Ja, det var inte ett junitest hoppas jag.
Nej, då hade det kanske varit över någon typ av gräns.
Du testar en sak.
Jag testar en sak, men väldigt noggrant.
Nej, det var ett en-till-en-test skrivet med Playwright.
Jag tror kanske att jag pratade lite grann om en-till-en-testet förut i podden någon gång.
Men fan vad jag älskar Playwright. Det är så jäkla trevligt att jobba med.
Och det här en-till-en-testet, om man ska förklara vad det gör så att folk fattar.
Jag försökte skriva en sammanfattning på det.
Så du behövde skriva dokumentation på ditt test som i sig är dokumentation?
Ja, lite grann. Men det var typ att jag ville skicka det till folk som inte utvecklade det.
Och bara så här, nu har vi det här testet. Det kommer testa de här sakerna.
Och jag tror att det är, vad kan det vara? Ska vi säga att det är 200 steg kanske?
Hur lång tid tar det att köra?
Ja, det är en bra fråga. Det kan vi också titta på.
När man kör lokalt så tar det typ två minuter, tror jag.
Och sen är ju frågan hur lång tid det tar när man kör i vår pipeline.
För det gör vi ju. Totaltid 7.51, men det är nog inte bara det testet. Det är nog lite fler test.
Det är väl rätt okej ändå säkert. Men är det så att ni har någon githook som måste köra det varje gång ni ska kommitta eller pusha?
Nej, alltså den stoppar inget.
Utan den här en-till-en-testen kör bara på sidan om och skriker om någonting går fel.
Men det är väldigt trevligt. Och jag satt ändå och i början klurade lite på så här,
fan ska vi skriva allt det här som ett test? Eller ska jag dela upp det i fler test?
Men landade liksom i att, vad har vi testat och skrivit det som ett jättelångt test?
Och då ser vi hur långt det blir och om det blir bra eller inte.
Och för lite kontext då, så det jag bygger är ett rekryteringssystem.
Och då går det ut på att man som användare så finns det ett ganska långt flöde framförallt.
Som är att man skriver ner vilka krav man har på en tjänst. Man publicerar en annons med de här kraven.
Man förbereder sina intervjuer eller sina mallar som man ska ha intervjuerna på.
Man håller intervjuerna utifrån mallarna. Man utvärderar kandidaterna.
Man bokar in möten och intervjuerna med dem under tiden.
Och till slut så godkänner man eller tackar nej till kandidaterna.
Och det som gör att jag inte ens ville skriva det här som flera tester var att all den här datan beror på varann.
De kraven du sätter i det första steget, de ska vara med och utvärderas i sista steget.
Och de ska vara med i intervjuerna och de ska visas upp på ansökan som har kommit in och allt sånt.
Och jag kände bara så här, fan det som alltid blir jobbigt när man skriver tester
är ju att man måste manuellt skapa upp massa data.
Så att för att kunna testa utvärderingen i det här fallet, om jag bara ville göra det där,
så hade jag behövt skapa upp en massa utvärderingar på den här kandidaten.
Eller skapa upp någon intervju där de har gjort den här utvärderingen manuellt, ner i databasen bara.
Och det är, i min erfarenhet så ställer det alltid bara till mer problem än vad det hjälper.
Och då kände jag, men vad fan, jag kan ju göra så att i testet så skapar testanvändaren all data jag behöver.
Jo, jag fattar ju den grejen och det är ju jäkligt smutst.
Men jag tror också att det är en otrolig happy path.
Alltså det är ju inte bara att allting går precis som förväntat och att den användare använder systemet
precis som ni har förväntat er, utan det är att de gör det sekvensiellt, utan en enda paus,
utan en enda, liksom, plocka upp ett steg senare.
Blir det ett problem?
Det finns ju liksom ingen tidsaspekt riktigt i alla steg, utan det känns som att
den här testen är ett flöde, sen spelar det egentligen ingen roll om det skiljer en dag, två dagar eller en vecka mellan att man gör något steg.
Datan kommer ju se likadan ut.
Sen är det ju verkligen så att jag testar ju inga edge cases i det här testet.
Det här är ju väldigt tydligt happy flow för att se att det funkar.
Syftet med testet är verkligen att eftersom allting hänger ihop så mycket så vill jag se till att
om vi gör någonting på ett ställe så ska inte det paja någonting annat.
Det blir också en grej att om jag skapar upp massa data manuellt i testerna så kanske man inte vet att
två saker som hänger ihop väldigt mycket, som man testat separat, att man har förstört kopplingen mellan dem.
Det är där jag var ute efter att faktiskt testa.
Jag förstår verkligen grejen.
Jag förstår verkligen varför du gör det och det är säkert toppen.
Men jag bara känner tröttheten av att komma in i det här teamet, göra någonting, paja det här testet någonstans
och se mig in i den här filen och bara ""ja, det här ska jag fixa nu"".
Jag bara känner tröttheten komma över mig.
Det kommer ju vara en utmaning, det kommer ju oundvikligen hända, att det här testet pajar.
Det kommer också vara oundvikligen så att det funkar lokalt.
Men när man kör upp det i pipelinen så pajar det, skickar ut de fel som är typ ""på rad 745 så failade den här expecten som vi har här"".
Och det säger ingenting om varför den har failat.
Det är bara att någonstans i de här tidigare 744-raderna så har vi förstört någonting.
Ja, för att alltså, jag menar, inte för att vara sån, men i min erfarenhet så är ju end-to-end LSE-ledning testet det mest flaky vi har.
Jag kanske bara byggt dem dåligt, jag vet inte.
Jo, absolut. Selenium, samma erfarenhet.
Cypress, samma erfarenhet.
Playwright, så jävla bra.
Alltså jag har ju inte testat än, men jag såg ju snacket där en från Playwright gick igenom.
Det verkar jävligt nice, jag är ju verkligen sugen på att testa det.
Men det är ju sällan jag sätter mig ner och skriver ett test för att jag känner för det.
Bara för att jag kommer ihåg hennes namn nu så var det väl Debbie O'Brien, va?
Från Microsoft tror jag, som sitter i Playwright-teamet.
Jag tror hennes snack finns väl på Youtube, så vi kan väl länka det.
Det var ju också då jag plockade upp Playwright.
Men det är någonting med Playwright som gör att det är väldigt trevligt.
De har ju typ lånat API från Testing Library, alltså som ReactTester Library Review.
Alltså att du testar från användarperspektiv i det att du ska inte använda CSS-selektorer för att ta tag i element.
Du ska inte querya sånt, du ska bara testa från användaren.
Så typ, jag vill klicka på en knapp som det står det här på.
Jo, men samarbetade de inte också med, om det var Kency Dodds eller Testing Library, sa de?
Jo, det var inte att de bara snodde det rakt av, utan det var nog väldigt tydligt att
det här API är svinajs, vi vill köra i Playwright också.
Jo, men att de har gått igenom det tillsammans och jobbat med det och itererat över det tillsammans.
Ja, så kan det verkligen vara.
Men det är i alla fall inbyggt i Playwright, så du behöver inte ett Playwright Testing Library som wrapper.
Nej, men alltså jag gillar ju Testing Library, det måste jag ju ändå säga.
Ja, och jag vet inte, det är någonting med allt det här som gör det väldigt bra.
Playwright är också väldigt bra på att göra, när någonting faktiskt går fel, som händer hela tiden,
så har de ändå väldigt bra verktyg för att lösa det.
För det ena så är det att de spelar in en film på allt de gör, om man vill.
Så du kan få ut en film som är i en browser, de visar allting, så de har klickat på allting de har gjort.
Sen kan man få ut något som de kallar för en trace, och det är liksom att de har
Jag tänkte att du har spelat in, eller du har sparat ett snapshot av statet i webbläsaren
mellan varje action som tas.
Så att du kan till exempel öppna upp den i en browser och köra inspect för att kolla hur var statet i det här.
Du kan se nätverksloggen, du kan se konsolloggen, du kan se allting sånt och felsöka utifrån det.
Sen har de också en väldigt bra debugger, som är att du kan köra igång tester lokalt
och så kan du steppa igenom det med en debugger.
Enda jag stömmer på är att jag inte hittat att det går att sätta breakpoints.
Så att klickar man play så måste man vara med på pausknappen, när man vill stanna,
istället för att man bara kan stanna av sig själv.
Och i ett test som är tusen rader långt och tar två minuter att köra så är det lite jobbigt
om man missar det man vill stanna inför när man har kommit halvvägs.
Jag undrar om de hade det scenariot i åtanke när de gjorde det här.
""Åh, men tusen rader långt test, absolut!""
Jag vet inte om det är långt.
Det är absolut det längsta testet jag har skrivit i hela mitt liv.
Men det känns så jävla bra nu. Jag vill bara skriva långa tester.
Men, usch.
Men alltså, hade inte de någon sån här grej också där du kunde sätta upp hela skalet av testet
genom att klicka i guvet?
Jo, precis. Det är ungefär samma som du använder till Cinderbugger,
alltså samma tooling, att du kan spela in vad du klickar på.
Min erfarenhet, jag har inte kört det jättemycket,
min erfarenhet är att den ger oftast mer selekta på den här CSS-klassen.
Och så blir det en lång CSS-selektor med ""den ska ha en direct child som är det här""
""som har en sibling som är det där"" med den här CSS-klassen.
Och det blir ju flaky direkt. Särskilt när man, som de flesta gör idag,
kör genererade CSS-klasser. För då smäller ju testet så fort det bygger om.
Mm.
Så jag tycker det är väldigt bra. Och också så här, mycket smarta grejer.
Typ att när man kör i, eller det finns en config som man kan ställa in
att den ska retrya testerna. Så att om de smäller, och på grund av att de är flaky till exempel,
då kan den liksom, ""ja men jag har tre retries"" så då kör den bara om testerna.
Och fortsätter. Och sen om det smäller efter tre, då smäller hela testet.
Men också då att då finns det liksom config som hänger ihop med den här trace,
alltså ska jag spara en trace eller inte? Då finns det typ ""ja den är på"" eller ""av"".
Men det kan också vara att den är på på första retryen.
Så att du liksom får inte overheaden på att spela in trace när du kör testerna
och de funkar. Så då går testet snabbt, eller snabbare, när de funkar.
Men smäller de, då kommer den att retrya och så kommer den att spara ner en trace andra gången.
Vilket gör att testet tar lite längre tid att köra, men det spelar ingen roll.
Och det känns genomtänkt.
Overhead.
Ja men det måste jag säga, jag gillar också så här retriesen, då kan den ligga i pipen
och bara ticka pengar.
Nej jag skojar bara.
Jag undrar om min kund betalar för de här utröna retriesen jag kör.
Jag vet inte riktigt.
Vi kör, alltså jag tror inte, det är inte så många som kör, vi kör den i GitHub
på just en-till-en testerna och sen har vi en annan egen pipeline för
liksom själva bygget och sånt.
Men jag tror inte så många andra team kör det, så jag tänker att vi ligger säkert
under någon gräns. Det är säkert lugnt.
Jag hade jäkla problem i CircleCI med flaky tester, att man bara körde om och om igen
och det bara... pengar.
Ja, det kan jag förstå.
Slurpade pengar.
Ja, nej vet inte, så nu sitter jag och funderar på om jag ska skriva lite fler tester
som täcker edge cases liksom.
Och då kan man ju kanske, då behöver man inte göra dem tusen rader långa,
tänker jag mig.
Men om du också då för dina edge cases behöver hitta ett sätt för att generera upp datan.
Ja, jag vet, då är jag liksom tillbaka på allt.
Då går det liksom.
Då hade du ju lika gärna kunnat splitta upp där.
Vad säger resten av teamet om det här beteendet? Är de nöjda?
Nej, alltså vi må programmera ju 100% egentligen.
Men det här har du 100% gjort på skuggorna.
Ja, det här är exakt. Det här är liksom saker jag har gjort samtidigt som jag har stött i samtal med de andra
och varit halvengagerad så har jag liksom stött och skrivit det här testet i tre dagar
utan att någon har riktigt tänkt på det.
Och sen så berättade de, just det hörrni, kan ni kodgranska mitt test?
Det är bara tusen rader.
Kan ni kodgranska mitt tusen radertest?
Fy fan vad äckligt.
De sa, nej det tänker vi inte göra.
Och då sa jag, okej då mörks det ja.
[skratt]
Så att vi har inte så stark kodgranskningskultur i teamet i och med att vi må programmera heller.
Så att det fanns inte en chans att någon skulle kolla den där koden.
Nej, det är också ett test.
Ja, exakt. Det är inte hela världen om det smäller.
Men när jag skrev det här testet så hittade jag kanske tre små buggar som behövde fixas.
Så det är ändå något.
Men har du gjort den här filen bra nu?
Har du separerat den ut den i olika sektioner där du har headlines över vilken sektion och vilket steg du befinner dig på
så att den i alla fall är läsbar så att man ser tydligt det här, det här, det här?
Den är absolut läsbar.
Jag har kommentarer på vad den gör i olika steg.
Och jag ska säga att Playwright är ganska lättläst ändå.
Det är typ ofta så här ""await page.getbyrollbutton name bla bla bla""
Det är svårt att missuppfatta vad den koden gör.
Ja, man tycker ju det när man är mitt inne i saker också.
Och sen så sitter man där och kollar på ett Capybara-test i Ruby on Rails.
Det är så folk kommer känna sig när de tittar på det här testet om ett halvår igen.
Även jag kanske, om det ska sägas.
Ja, du bara ""men jag skrev jättebra kommentarer"".
Ja, för att du var i kontexten.
För att det maked sense i kontexten.
Det är mycket möjligt att det är det som är verkligheten.
Men det som också, jag vet inte, om jag ska återkomma till just end-to-end-tester
det jag också tycker är nice är att vi har fått till en setup där vi verkligen testar så mycket som möjligt.
Alltså vi spinner upp en Postgres-databas till exempel när vi kör våra tester.
Som vi kör in alla våra databas-migreringar mot.
Och sen på den i sin tur så mockar vi nästan ingenting på tal om att stallägare gillar att testa det.
Så mockar vi nästan ingenting.
Eller så här, vi mockar ju, men vi mockar inte i kod.
Utan vi kör ju mock-service-worker som jag väl har hyllat tidigare i poddens historia någon gång.
Det har jag glömt.
Du vet vad mock-service-worker är ändå?
Nej.
Jo...
Nej, det är en service-worker som mockar saker.
Ja, typ så.
Jag försökte söka nu och se om jag hade pratat om det här förut, men det kanske jag inte har.
Någon kan påminna mig om det är så.
Du för världen framåt, det här har vi ju pratat om.
Avsnitt 78 kan man lyssna på, där pratar jag om också mock-service-worker.
Det är ju ett verktyg som gör att man liksom, du mockar inte i själva applikationskoden utan den ligger och fångar upp alla nätverksanrop som görs.
Och så kan man liksom, du kan svara, det blir som att du, den tjänsten du anropar, som att den svarar tillbaka i koden.
Så du behöver inte liksom mocka några tjänster, ingenting.
Och det är också så sjukt trevligt.
Och själva requesterna kan du testa hela liksom.
Ja, exakt.
Request-flödet.
Exakt. Så det gör ju också att en-till-en-tester blir väldigt trevliga.
Typ, nu till exempel så satt vi, vi har liksom en mail-tjänst där vi skickar massa mail ifrån.
Och nu testar jag den i det här en-till-en-flödet genom att jag skriver ner i den här mock-service-worker, den som fångar requestet.
Då skriver jag ner de fångade mailen till disk.
Och sen i mitt en-till-en-test så läser jag upp dem från disk och assertar att det har gått iväg liksom.
Och då vet jag ju att requestet har gått iväg, jag kommer veta att innehållet i mailet blev rätt och så vidare och så vidare.
Utan att faktiskt testa, eller liksom inspektera någon kod eller någonting sånt, eller vad som anropas med vad eller så.
Just det. Och det här kommer jag ihåg. Och du för världen framåt och jag är bara trött.
Ja, det kanske är en repris på det här avsnittet, det var inte så länge sedan, det är typ ett halvår sedan.
Ja, men typ alltså. Men det här, alltså för att, det är ju ganska nice att spinna upp en tom databas som man sen bara purgerar liksom.
Och så får allting bara köra där. Och det kommer jag ihåg att jag försökte med en gång i mitt liv.
Gav upp, grät en skvätt och konstaterade att jag inte för världen framåt.
Här ska jag verkligen erkänna att det här är inte jag som har gjort. Det här är någon kollega till mig som har kanske skrivit, kanske kopierat från någon annan tjänst på bygget.
Där de liksom typ, alltså det är en jävla källskript som jag vet verkligen inte vad den gör för något.
Men hur funkar det där då, är det en dockermiljö som man kör allting i? Så att okej, jag spinner upp den här dbn och sen så kör jag mot den i mina tester, bla bla bla och allt i samma miljö. Eller hur funkar det?
Ja, eller så här, det är väl egentligen två sätt för oss. Vi har en lokal setup som spinner upp en postgres server lokalt och den tror jag bara kör på att du har postgres installerat på datorn, tror jag.
Har du inte postgres då kommer det gå åt helvete?
Ja, jag tror det. Jag försöker hitta koden nu men det är så jävla många filer och så jävla många config filer ifrån den projekten.
Så den bara tycker att den spinner upp en db på en specifik path och den ska du bara ha lokalt?
Ja, precis. Jag tror att det är så. Jag hittar verkligen inte vart det här var. Men det är när man kör lokalt och sen när man kör i, för sen vi kör GitHub Actions som sagt och då i den action konfigurationen eller yaml-filen.
Då kan man spinna upp en postgres i den. Alltså du spesar bara att jag vill ha en service som heter postgres och den ska ha de här värdena och så vidare. Och då finns det i GitHub Actions som en tjänst.
Ja, ja, som en särdhet. Det heter väl inte orb i GitHub Actions säkert. Något typ av sånt.
Ja, jag kommer inte ihåg. Något typ services. Jag kommer inte ihåg. Man spesar att jag vill ha den här servicen. Kanske att den använder docker image för att spinna upp det här. Och sen är det väl typ det.
Så det är, jag vet inte.
När man inser att man måste in och dabla i en yaml-fila så, fy fan.
Men det är typ samma sak. Jag tror att för våra, vi har ju lite tester som faktiskt kör på varje commit också. Eller som kör i vår vanliga pipeline.
Men det är mer integrationstester. Och de kör faktiskt också mot databasen. Och de tror jag spinner upp en postgres in memory liksom.
Kan du förklara för mig vad ett integrationsteste är? Är det som ett kontrakttest?
Det här är ju den eviga frågan. Vad är integration? Vad är end-to-end? Vad är smoke? Vad är unit? Vad har vi mer?
Ja, men alltså unit är ju det de vanliga små. End-to-end för mig är ju ofta ui-test. Klikklicklicklick.
Sen är det ju det här med integrationstest. Och jag vet aldrig vad folk menar när de säger integrationstest.
Nej, alltså jag tror vi kallar det integrationstest för att det är inte ett end-to-end-test. Och det är inte ett unit-test.
Utan det är någonstans mitt emellan. Alltså våra tester testar ofta typ så här, kanske en hel tjänst men även med integrationen till databasen.
Eller typ så här, vi kanske testar, vi har några väldigt komplicerade databas-transaktioner. Sen kör vi prisma så att det går via prisma.
Sen går vi via det som vi testar där och då vill vi testa att det blir rätt i databasen också. Så de spinner upp en test, eller de spinner inte upp en test, de spinner upp en databas.
Och sen testar de specifika funktioner som går mot databasen. Alltså hur de integrerar kanske då med databasen.
Ja, vilket är logiskt och det är väl så jag tänkt att det är. Att det också skulle kunna vara, ja men typ som kontrakttest.
Alltså det här API-erna, snackar de med varandra på rätt sätt som vi förväntar oss att de ska göra.
Men ja, bara förvirrad. Egentligen är det logiskt men ändå förvirrad. Som vanligt, skulle jag vilja säga.
Ja, men det där är svimförvirrande. Och då känns det som att varje gång man kommer till ett nytt ställe så kallar de testen för olika.
Det är samma sak med smoke-test. Det är också en sån grej som jag bara så här, vad är skillnaden mot en-till-en-test?
Men nu tänker jag att smoke-test är typ QA. Alltså typ mitt superduper tusen raders test nu är väl typ ett smoke-test. Att se så här, ja men ingenting har gått sönder.
Men är det ett smoke-test? Alltså jag tycker att ett smoke-test är att man bara testar att det är mest basic fungerar, typ renderar det?
Ja, kanske. Ja, det är sant. Det kan det också vara kanske.
Är det rök liksom, när det förväntas vara det?
Ja, det kanske är sant. Det har du nog rätt i.
Men jag vet inte. Jag vet verkligen inte. Jag är bara glad att jag inte behöver göra. Jag håller mig till unitest oftast, kanske ui-test.
När folk börjar snacka lasttest och sånt, då bara drar jag. Då checkar jag ut.
Ja, lasttester har jag sysslat med lite tidigare i min karriär. Har jag berättat om, det här måste väl vara preskriberat nu, när jag jobbade på Systembolaget
och typ höll på att sänka deras autentiserings-server, inte för externa tjänster utan för alla användare på Systembolaget.
Alltså de kunde inte logga in på sin dator, typ.
Alltså du har ju berättat det för mig, det vet jag ju. Men i vilken kontext du har berättat det, det vet jag inte.
Jag har kollat på vad som sägs i podden och vad som inte sägs. Men det var så här, att jag byggde lite lasttester via något.
Jag tror det var något gammalt Visual Studio verktyg. Om man körde Visual Studio Enterprise så fick man med någon typ av verktyg för att bygga lasttester.
Och de här lasttesterna skrev jag själv. Jag skulle bara göra lite basic-grejer på några nya tjänster jag hade byggt.
Och då fungerade det så att man körde den här från sin dator men man fick installera olika agenter.
Och så skulle man ha ett gäng agenter så att alla agenter kunde skicka en viss mängd trafik.
Så i vår datahall så installerade jag det här på lite slumpfalt utvalda maskiner.
Det var någon som körde någon liten intern tjänst som inte användes ofta. Det var någon som bara låg där och hade någon fileserver.
Så där installerade jag lite sådana här blandade på 5-6 stycken.
Vad är det värsta som kan hända?
Det här är det sjuka. Jag installerade det på mitt konto. Det var inga konstigheter. Jag gjorde det väldigt mycket med allas approval.
Så jag gjorde det här, vi körde lasttesterna. Allting fungerade utmärkt. Alltså inga konstigheter. Jag stängde av lasttesterna.
Gick vidare i livet. Och sen kan det ha varit en två och en halv månad senare så ringer en person från mig från företaget som skötte infrastrukturen.
Och bara tja, vi ser att din användare försöker logga in här med fel lösnord på vår autentisering server typ 3000 gånger i sekunden.
Och jag bara, va? Går tillbaka till min dator. Min dator står framför mig, är upplåst. Jag bara, jag sitter och tittar på min dator nu. Det är inga konstigheter.
Han bara, jag vet inte vad det kan vara. Jag bara, jag kan stänga av den. Jag stängde av min dator. Hände fortfarande ingenting.
Fick gå ner till en mötesrum där de satt. Jag bara, det är ingenting.
Jag bara, vad fan kan ni inte se? Vart kommer trafiken ifrån?
Han bara, jo men den kommer från fem olika servrar där. Det är de här namnen.
Och jag bara, nu börjar det ringa någon liten klocka i mig.
Och jag bara, men vad fan har det här med mitt användarande av lösnord? Varför sitter det ändå pengar där hela tiden?
Och då kom jag på det. Det hade varit obligatoriskt lösnordsbyte den morgonen. Så jag hade bytt lösnord på mitt konto.
Och de här agenterna var tydligen så jävla usla. Så att om de fick, nej det gick inte att logga in. Vad gjorde de? De försökte igen.
Och mitt gamla lösnord var bara inställt på de här agenterna. Så de låg och pingade den här inloggningsservern för att bara kolla.
Vi lever, det är lugnt. Vi finns här.
Men vad var meningen att de bara skulle fortsätta köra i evighet?
Nej, alltså jag avinstallerade dem inte. Men jag hade ju inte en tanke på att de skulle pinga den här jävla servern för att de låg installerade.
Så du körde en gång och städade inte ordentligt?
Jag avinstallerade dem inte efteråt. Det gjorde jag inte. För jag tänkte ändå att vi kanske gör det här någon mer gång. Det kan vara bra att ha kvar dem där.
Men de bara levde vidare?
De levde vidare tills de blev upptäckta av att jag hade blivit tvingad att byta lösnord. Vilket också är en jävla urusel policy. Utan den hade det aldrig hänt.
Tills du slutade?
Ja det är sant och då hade det varit ännu värre.
Då tycker jag ändå att det är najs kanske att det skedde när det fortfarande var kvar.
Det finns en poäng där, det gör det absolut.
Med det så säger vi väl tack för oss för idag kanske?
Ja.
Vi säger så och så hörs vi snart igen.
Hör min energi. Ha det fint allihopa. Hej då.
Hej då.
