sicutdeux@blog : ~/blog $ cat dos-escritores-en-sqlite.md
theme:auto
sicutdeux@blog:~/blog$cat dos-escritores-en-sqlite.md

Dos escritores en SQLite (y por qué WAL me hizo perder la fe en los mocks)

---
slug:
dos-escritores-en-sqlite
title:
Dos escritores en SQLite (y por qué WAL me hizo perder la fe en los mocks)
published:
2026-05-16
updated:
2026-05-19
author:
sicutdeux
lang:
es
tags:
[go, infra, sqlite]
reading_minutes:
11
---

Dos escritores en SQLite

Cuando mockeas la base de datos en tests de integración, lo que pasa es que terminás creyéndote tu propia ficción. SQLite con WAL aguanta múltiples readers concurrentes y un solo writer; eso lo sabe cualquiera que haya leído el manual.

Lo que NO te dicen es que cuando tenés dos procesos escribiendo (blog web y worker cron), las escrituras se serializan via _busy_timeout. En tests con mock, todo es perfecto. En producción, una migration tarda 8 segundos y el segundo writer se da timeout.

Lección

No mockeés la DB en tests de integración. Levantá una real con t.TempDir(). Aprendí porque me confié.

func TestRealDB(t *testing.T) {
    sqlDB, _ := db.Open(filepath.Join(t.TempDir(), "test.db"))
    defer sqlDB.Close()
    db.Migrate(sqlDB)
    // ...
}

El t.TempDir() se autoborra. Cero overhead. Tests reales > tests bonitos.