BookinglyTech News
Software

Práctica de tests en Gleam: un caso de uso concreto

Un desarrollador comparte un test real de una app de bookmarks escrita en Gleam, explicando su estructura, dependencias y estilo de nombres.

2 min de lecturaLobsters0 vistas

Análisis de un test en Gleam

El autor presenta un test para la función store.start_job(conn, job) de un proyecto de bookmarks. La función debe marcar un job como iniciado y eliminarlo de la lista de pendientes. El test se ubica en test/bookmarker/store_test.gleam y sigue la convención de Gleam de colocar los archivos de prueba en un directorio paralelo a src.

Estructura del test

pub fn start_job_marks_running_test () {
  use conn, Deps(clock: _, ..) <- with_test_conn()
  mock_clock.set(clock, ts("2026-01-05T00:05:10Z"))
  let assert Ok(bookmark) = store.add_bookmark(conn, "http://example.com")
  let assert Ok(job) = store.schedule_job(conn, bookmark)
  let started_at = ts("2026-01-05T00:06:00Z")
  mock_clock.set(clock, started_at)
  let assert Ok(option.Some(started)) = store.start_job(conn, job)
  started.id |> should.equal(job.id)
  started.bookmark |> should.equal(bookmark.id)
  started.created_at |> should.equal(job.created_at)
  started.status |> should.equal(store.Running(started_at:))
  store.list_pending_jobs(conn) |> should.equal(Ok([]))
}

El test utiliza use para el manejo de recursos, similar a with en Python. La sintaxis started.id |> should.equal(job.id) aprovecha el operador pipe de Gleam para una lectura fluida. let assert actúa como unwrap de Rust, lanzando una excepción si la llamada falla.

Dependencias y constructor

Para evitar repetir boilerplate, el autor define un constructor de prueba:

fn with_test_conn(f: fn(StoreConn, Deps) -> a) -> a {
  use db <- db.with_connection(":memory:")
  let assert Ok(schema) = simplifile.read("db/schema.sql")
  let assert Ok(Nil) = sqlight.exec(schema, on: db)
  let clock = mock_clock.new(timestamp.from_unix_seconds(0))
  f(store.new(db, mock_clock.now(clock)), Deps(db: db, clock: clock))
}

Deps agrupa la conexión SQLite y el reloj falso. El constructor prepara el esquema y devuelve las dependencias al bloque de prueba. Esta técnica evita duplicar código y facilita la configuración de pruebas unitarias.

Nombres de pruebas

El autor prefiere nombres de prueba como cadenas para mayor legibilidad: test("start_job marks a job as running"). Gleam permite usar caracteres especiales en el nombre, lo que evita ambigüedades con subrayados. El enfoque destaca la intención del test en lugar de detalles de implementación.

Relevancia para el lector

Para un administrador de sistemas o arquitecto que trabaja con Gleam o similares, el artículo ofrece:

  • Una referencia concreta de cómo estructurar tests con recursos externos (SQLite, reloj mock).
  • Un ejemplo de manejo de dependencias y cleanup automático con use.
  • Buenas prácticas sobre nombres de pruebas y separación de código de prueba y producción.

Si tu stack incluye Gleam, o buscas patrones de pruebas en lenguajes funcionales, este caso sirve como plantilla práctica.

Conclusión

El post demuestra que, aun en proyectos pequeños, es posible escribir tests claros, bien estructurados y con dependencias controladas. La técnica del constructor de pruebas reduce la repetición y mejora la mantenibilidad. Para cualquier equipo que esté adoptando Gleam, estos ejemplos pueden acelerar la curva de aprendizaje y garantizar pruebas robustas.

Historias Relacionadas