Vlákno názorů k článku Jazyk Go prakticky: jednotkové testy kódu, který přistupuje k SQL databázím od atarist - už jsem viděl v jiných jazycích, jak lidi...

už jsem viděl v jiných jazycích, jak lidi mastili unit testy oproti reálné databázi. jenže to pořád chtělo izolaci testů, takže cleanup, to mi nepřipadlo moc jak test "unit". možná by bylo lepší mít in-memory DB, ale zase - co se tím vlastně testuje? skutečně unita nebo spíš ta DB?

No striktně řečeno to nejsou jednotkové testy. Navíc ta in-memory DB se může chovat jinak než reálná DB (SQLite in memory je odlišná od PostgreSQL atd.), takže sice se něco otestuje, ale mocky by to chtělo. Třeba v Pythonu je to ještě snažší než v Go.

takže to jsou spíše integrační testy že?

Tak nějak. Ono to použití reálné databáze (taky jsme to měli v jednom projektu) vede k tomu, že se vše tváří ok, i když ty dotazy ve skutečnosti můžou být úplně špatně; navíc ty unit testy fakt nemají testovat DB, ale daný kus kódu. Na druhou stranu v integračních testech (nebo možná raději v BDD) to smysl dává a velký.

Ale zalozit si 'cistu' DB mozete ako sucast testu aj s PostgreSQL aj s Oracle.

Jj určitě je to možné a taky jsme to tak řešili. Jen je nutný nezapomínat na striktní setup/teardown pro každý unit test, zajišťovat dostupnost DB z CI atd., hlídat si, až se nehromadí temporary DB (což PostgreSQL do jisté míry umí automaticky per connection) apod. Určitě je to doable a pro e2e a integrační testy asi nic jiného nezbývá.

a pak stejně neotestuješ věci jako chybějící indexy, špatně nastavený shardering a jiné záludnosti pokud databáze začne růst. Připadá mi, že tohle řešení občas bere více energie a času než ho nahradit unit testy a pořádnými integračními, které mohou běžet delší dobu nad více daty.