Ett av stegene i en iterasjon er å se. Hva skjedde? Funka det? Brakk du noe annet? Det hender du kan se alt du trenger med en kjapp browser-refresh, og det hender at en browser refresh ikke gir deg det du trenger. Så avhengig av hva vi legger i "iterasjon", tror jeg jeg er enig. Så lenge det ikke er at vi flikker på én bit av systemet og ignorerer en annen viktig bit.

jeg er nok litt sær på tradeoffen mellom rask feedback og “riktig” feedback. Konkret der så mener jeg at jeg er sykt allergisk til mocks, og at jeg gjerne vil at feedbacken jeg får skal være så lik produksjonssystemet som mulig. Aka kall databasen mest mulig i testene, for å ta et eksempel. Rask feedback som ikke sier noe som systemet slik det faktisk kjører i prod ser jeg på som ganske så ubrukelig feedback, for å si det på en annen måte

Ja - jeg har følt litt på det samme Jo mer som må "konfigureres" forskjellig i test og prod, jo mer kan gå feil mellom. Dette synes jeg faktisk ofte er mer rett fram i js-kodebaser og go-kodebaser. Du tenker ikke på at du cul kjøre "biter" av systemet ditt (som feks med integrant), du bare kjører alt sammen.

@U0MKRS1FX når du jobber i clojure, pleier du å ha en kjørende database mens du kjører testene? Jeg har tenkt litt på hvordan akkurat det kan gjøres. Jeg skrev noe kode i vår der jeg lagde en protokoll for interaksjonen med databasen (defprotocol), så hadde vi Implementasjoner (defrecord) for mariadb, in-memory og mappe på disk. Hvis vi hadde droppet det og alltid jobbet mot mariadb, hadde ting blitt enklere, og vi hadde måttet skrive mindre kode. Men hvordan organiserer vi da testene? Atom i toppen av testfila der det kanskje er en db-conn, så kjører testene mot den hvis den finnes? Dynamisk variabel? Tester som krever db-conn et eget sted, så kjøres de på en egen måte, og db-conn er alltid tilgjengelig når de kjører?

Alltid ha en instans av MariaDB tilgjengelig for testene. Om den ikke finnes, skriv ut en feilmelding som forklarer at du må ha en instans av MariaDB tilgjengelig.

(Dette er forøvrig hvorfor jeg liker sqlite når du kan bruke det: Det er raskt, kan være in-memory og krever ingen eksterne prosesser)

ja, pleier å ha en kjørende database, gjerne via docker-compose o.l så det er lett å drepe den og starte ny instans osv

Du kan jo bruke testcontainers for å kjøre opp en database under kjøring av tester. Hvor lett det er, kommer kanskje an på CI-løsningen du bruker også.

Hvilket problem er det testcontainsers løser da? Hvorfor ikke docker compose?

Det er en løsning for å kjøre opp Docker containers for å kjøre integrasjonstester mot. Det gjør det blant annet enkelt å kjøre testene dine mot forskjellige databaseversjoner eller forskjellige databaser. Akkurat det er jo mest nyttig for biblioteker. Men litt sånn som i Github Actions og liknende hvor du tester en løsning mot forskjellige versjoner av Clojure og operativsystemer ved å liste opp hvilke versjoner av de forskjellige du skal teste mot.

Den spinner også opp en ny container automatisk for kjøring av testene, så den håndterer intialisering og teardown av containerne for deg.

Datomic har innebygget støtte for in-memory-lagring 👌

Men føler allikevel at den diskusjonen er en liten avsporing. Et REPL løser nøyaktig det problemet som August opprinnelig beskrev: du er inne i selve prosessen og kan se på og tukle med alt sammen. Ikke en mock i sikte.

Ja, men har hatt nok av problemer med H2 og kjøring av tester til at jeg foretrekker å bruke samme versjon av riktig DB til å kjøre tester.

Og også når jeg kjører applikasjoner i utviklingsmiljøet og bruker REPL.

> Ja, men har hatt nok av problemer med H2 og kjøring av tester til at jeg foretrekker å bruke samme versjon av riktig DB til å kjøre tester. > To pirkete poenger: 1. Hvis man kjører testene fra inni REPL og har en lokalt database-tilkobling fra REPL, kan man kjøre testene mot egen db 2. Tiltaket jeg gjorde i tidligere i år med tester, var ikke å bruke h2 - det var å innføre en protokoll i egen kode med flere Implementasjoner bak

Men det er kanskje litt det du mener?

> Datomic har innebygget støtte for in-memory-lagring 👌 > Med Datomic er dette mye lettere å få til bra, ja!

Har som regel bare brukt H2 i enhetstester før, og det er ikke så ofte jeg kjører dem fra REPL. Men, ja, hvis du lager en slik protokoll, og skal teste den mot forskjellige eksterne lagringssystemer, kan det være relevant å ha automatisk starting av riktige containere definert i project.clj/build.clj/pom.xml eller hva nå enn man bruker.

I Clojure blir det vel en fort manuell styring av testcontainers lifecycle-messig. Finnes en kaocha-plugin om du bruker kaocha til testing. Ikke det at det er så fryktelig vanskelig å definere noen fixtures og sette opp når og hvordan containere skal spinnes opp.

Finnes en modul for å bruke Docker Compose istedenfor å definere containers i koden. Ellers støttes jo vanlige Dockerfiles i kjernen. Vet ikke om Java-moduler er enkelt å bruke sammen med testcontainers-clj, men skulle tro at det lar seg gjøre. https://java.testcontainers.org/modules/docker_compose/

Takk for forklaring! Mulig jeg må se mer på testcontainers. Ser ut ut som det finnes en clojure-klient også: https://cljdoc.org/d/clj-test-containers/clj-test-containers/0.7.4/doc/readme