veldig kjekt å ha i et namespace ja. Da blir det lettere å gjøre triks som å bruke dynamiske bindings til en slags klient-sak som man kan bytte ut i tester. Men som regel gjør jeg ikke sånne ting, det holder med funksjoner for min del 🙂

altså typ (my-pure-business-logic "a" :b fundtion-that-invokes-external-api) , og i testene kan man bare sende inn en funksjon som returnerer noe mock-data

Man trenger vel den oftere når man ikke har nil punning!

ja, nettopp! Godt oppsummert

har drivi og nøsta when-let i alle år 🙂

Føler at mange clojure-funksjoner er skrevet sånn at man ikke trenger å tenke på det - feks (:make car) kontra car.getMake()

Hmm, det gjør jeg litt av også. Når du sier det, kunne jeg kanskje trengt litt some-> selv 😸

i dag er jeg SoMe influencer

The right kind of some!

Funksjoner og verdier er ofte nok! Og de har vi god støtte for :)

Det var kanskje min viktigste takeaway fra #clojuredesign-podcast, hvor de pratet mye om å "bygge opp et språk" i appen sin.

Jeg hørte om FC/IS for første gang i https://kodeskikknemnda.no/ep/3-magnar-sveen-adventur-delux/ med @U0MKRS1FX og @U07FCNURX, hvor de pratet om Adventur Delux.

Jeg har lest en del om det i etterkant, og tror jeg har forstått det rent teoretisk, men jeg sliter fortsatt litt med å forstå hvordan det ser ut i praksis helt konkret i måten Clojure-koden er organisert på. Eksemplene fra @U07FCNURX i https://clojurians.slack.com/archives/C061XGG1W/p1687869917478549?thread_ts=1687868159.124359&cid=C061XGG1W hjalp mye.

Ja, jeg brukte det for å skrive om en viktig, utrolig utestbar og imperativt batch job om til en fin, testbar greie i Clojure. Hent alle data i forkant => kjør pure logic => få ut ønsket effekter som data (untatt logging, der giddet jeg ikke og logga direkte) …

Jeg har skrevet litt om det her https://blog.jakubholy.net/defeating-legacy-code-with-living-documentation-and-business-level-tests/

Det synes jeg er en sterk misbruk av protokoler. Clj er ikke C#, vi kanskje ikke trenger å gjøre det samme. 100% testdekning er lett å måle, men jeg er usikker over verdien (spesielt når man begynner å teste getters osv. 🙀 ). Finnes det ikke bedre måter for å sikkre at du har gode tester en dette?

Du kan, men det har ikke samme effekt. Kompilatoren klager ikke ved delvis implementerte protokoller. Det blir kjøretidsfeil hvis du kaller en metode som ikke er implementert.

Kompilatoren vil uansett ikke sjekke om det er en faktisk test der - du kan jo implementere den med C#-ekvivalenten av (is true) , og kompilatoren er like glad og du har 100 % testdekning! 🙂

skulle ønske det var lett å lage sine egne lintere. F.eks når man skriver React er det jo veldig kjekt å få alle mulige linter-feil som er React-spesifikke, som at du har husket på å ha med alt som trengs i dependency-arrayet til useEffect. Og et krav som “husk å teste alle public funksjoner i namespace X” høres for meg mere ut som en linter-feature enn en compiler-feature

Jeg liker å skrive funksjoner som tar inn parametre. I test er parameterne satte verdier (maps, vektorer,...). I prod kommer de fra et annet sted i systemet.

Nå spør jeg kanskje dumt, men betyr det at du har "fixtures" (typ .json eller .edn) definert i koden din, eller lastet inn fra filer på disk i prosjektet ditt? Typ "mocks" nesten.

I C# pleier jeg å gjøre kall mot leverandørens API for å få et objekt. Så lagrer jeg det på disk, og bruker det til testene mine. Nå jobber jeg med API-et til en leverandør hvor dokumentasjonen er svært utdatert og misvisende, så det eneste jeg kan stole på er det som faktisk kommer ut av API-et 😅

Jeg liker å ha data i line i testene, gjerne ha testene veldig likt det jeg gjør i REPL. Eksempel (som helt sikkert ikke er perfekt): https://github.com/iterate/mikrobloggeriet/blob/04977c5452864d95549001ffde1121ebeb59c52d/test/mikrobloggeriet/cli_test.clj#L13

(veldig mange i denne kanalen som er veldig flinke på sånt, noen har til og med skrevet bøker om tester!)

(Stor takk til @U04V5VAUN som ga meg en code review på den koden. Etterpå splittet jeg ting opp, og det ble mulig å teste)

Kul idé også, med "mikroblog" (og artig navn, haha)

Navnet var det ikke jeg som kom på - det kom fra en fyr som heter Henrik! Skrev litt om motivasjonen min for hele greia her: https://play.teod.eu/mikrobloggeriet.no/

Synes det er viktig at vi tar læringen vår seriøst.

som regel har jeg bare funksjoner som inline i testen returnerer data, men det kommer litt an på oppsettet om det er noe dynamikk involvert

som regel er ikke dataene til disse eksterne systemene så veldig omfattende i mitt virke ihvertfall :)

Jeg sliter med å finne tid til det, men prøver :)