Open plimkilde opened 2 years ago
Godt forslag.
Jeg var tidligere meget tilfreds med Coveralls men gik væk fra det for et par år siden pga bøvl med tokens osv. Jeg kan se det nu integrerer godt med GitHub Actions så jeg giver det lidt en test igen. Jeg brugte codecov.com som erstatning. En af de to bør være anbefalingen.
Jeg har som test nu sat coveralls op på WEBPROJ: https://github.com/Kortforsyningen/WEBPROJ/pull/40
Det ser ud til at fungere fint. Eneste lille ting man skal være opmærksom på er at coveralls forventer at få coverage results i lcov-format hvilket pytest ikke kan spytte ud. Det var vist den egentlige årsag til at jeg migrerede væk i sin tid. Det fikses med værktøjet coveragepy-lcov der kan installeres med pip.
Her er eksempler på de to services:
coveralls: https://coveralls.io/github/OSGeo/PROJ codecov: https://app.codecov.io/gh/Kortforsyningen/FIRE
Begge to løser opgaven. Jeg tror umiddelbart coveralls giver lidt bedre feedback i checks under pull requests. Til gengæld giver codecov efter min mening et bedre visuelt overblik og kan konfigureres i en yml-fil direkte i git-arkivet.
Jeg kan umiddelbart leve med begge løsninger - er man nødt til at ofre pytests almindelige outputformat for fejlede tests for at kunne bruge Coveralls?
Jeg ved ikke hvor stort behovet er for at kunne lave hårde "fejlede" tjek med den pågældende tjeneste, men det er i hvert fald rart at kunne få rapporteret nogle tal på det.
er man nødt til at ofre pytests almindelige outputformat for fejlede tests for at kunne bruge Coveralls?
Nej. Det her output fra testkørslen på WEBPROJ:
Jeg ved ikke hvor stort behovet er for at kunne lave hårde "fejlede" tjek med den pågældende tjeneste
Det er ofte super irriterende men det er sgu meget godt at blive tvunget til at holde testsuiten i live
Det er ofte super irriterende men det er sgu meget godt at blive tvunget til at holde testsuiten i live
Ja - men på den anden side skal man heller ikke friste folk til at skrive en meningsløs test for at få fred. Så det må vel forudsætte at man samtidig har tilstrækkeligt med reviewkultur på plads på sit repo, så kun meningsfulde tests accepteres.
Den problemstilling kan du så forsøge at komme uden om ved at slå branch protection på main og have krav om mindst et positivt review før merge er muligt. Eller du kan gå ud fra at vi nok som udgangspunkt alle har gode intentioner :)
For at få bedre overblik over hvor man står mht. tests, kunne man nævne Coveralls eller et andet code coverage-værktøj (og guide til opsætning af dette). At få code coverage på gør det også mere kvantificerbart over for ledelse/kollegaer, hvor godt man er dækket ind med tests på sit projekt.