Canal Ruby Sur presenta

Cocineros
Rubyistas

Hoy: una suite de tests 5× más rápida,
sin sacar ni un solo test.

@fesilvajacquier · Meetup Ruby Sur · 20 de octubre de 2026

Ningún test
fue lastimado

Ficha de la receta

Plato: Suite de tests Rails, al horno
Porciones: 5.267 tests · 26.734 assertions
Cocina: App Rails 8.1 multi-tenant · Minitest · Postgres
Cocción original: 709 segundos
Cocción nueva: ~71 segundos
Dificultad: 🥄 Casi todo es configuración

Meme del esqueleto esperando en un banco: 'Yo esperando bin/rails test, 709 segundos'

11 minutos
y 49 segundos

Esta charla dura menos
que mi suite de tests.

Mise en placeLos ingredientes

🔥

1 línea descomentada

parallelize

🧂

1 pizca de sal

bcrypt al costo mínimo

🍽️

1 página de 404 barata

consider_all_requests_local

🗑️

3 cosas que nadie comía

SimpleCov · progress bar · Bullet

🔇

1 relator menos

log level warn

🥡

Postgres sin tupper

unlogged tables

Doña Petrona cocinando con varias ollas en el fuego

Paso 1Prender todas las hornallas

# test/test_helper.rb
# parallelize(workers: :number_of_processors)

Comentada desde el primer commit.
La suite usaba 1 hornalla de 8.

709 → 259 s

2,7× borrando un carácter

Meme de Salt Bae tirando sal: 'BCrypt::Engine.cost = MIN_COST'

Paso 2Una pizca de sal

Devise ya bajaba el costo en test.
Pero solo para Devise.

Nuestro código hasheaba códigos de firma con BCrypt::Password.create a costo 12. Un hash: 1,6 s. El test más lento: 29 s.

# test/test_helper.rb
BCrypt::Engine.cost = BCrypt::Engine::MIN_COST

−44 sBuscá BCrypt::Password.create en tu app

Meme de Scooby-Doo: al desenmascarar 'Tests de autorización lentos' aparece 'La página de 404 que lista todas las rutas'

Paso 3La 404 barata

Pediste un vaso de agua y el mozo te recita la carta entera.

Cada 404 renderizaba la página de desarrollo, con todas las rutas de la app: ~0,7 s por request. En una app multi-tenant, «un extraño recibe 404» es un test que se repite mucho.

# config/environments/test.rb
config.consider_all_requests_local = false

−27 s

Pasos 4, 5 y 6Lo que vuelve intacto a la cocina

📊

SimpleCov

Siempre prendido.
Nadie leía el reporte.

−19 s

📺

minitest-reporters

Redibuja la terminal
después de cada test.

−8 s

🔫

Bullet

Con raise = false:
nunca falla, solo loguea.

−3% CPU

Si no puede romper tu build, solo te cuesta tiempo.

Pasos cuatro, cinco y seis: lo que vuelve intacto a la cocina. Platos que salen, nadie toca, y vuelven. (Click.) SimpleCov, prendido en cada corrida. Nadie miraba el reporte. 19 segundos. (Click.) La barrita de progreso de minitest-reporters: redibuja la terminal después de cada test. 8 segundos. Los puntitos de Minitest ya te muestran los errores. (Click.) Y Bullet, el detector de N+1. Lo teníamos con raise en false, así que nunca rompía nada. Solo escribía un log. (Click.) La regla: si algo no puede romper tu build, solo te cuesta tiempo. Si querés coverage de vez en cuando: require simplecov if ENV COVERAGE. ~25 s Si preguntan por qué Bullet aparece como "−3% CPU" y no en segundos: en la notebook su ahorro queda dentro del ruido del reloj (±10 s), pero el CPU baja en cada corrida. En un benchmark de un solo proceso le sacó el 16% de CPU. La explicación completa está en las notas de la slide de CI.

Meme de Gordon Ramsay: '¿Qué sos?' 'Un Bullet con raise = false'

Paso 7Bajarle el volumen al relator

¡SELEEEEEECT!

En test, Rails loguea en debug: cada query se formatea
y se escribe en log/test.log, que llega a gigas.

# config/environments/test.rb
config.log_level = ENV.fetch("RAILS_LOG_LEVEL", "warn")

−16 sy −10% de CPU

Paso 8Postgres sin tupper

Los datos de test se tiran al final.
No hace falta que sobrevivan a un apagón.

# config/environments/test.rb
ActiveSupport.on_load(:active_record_postgresqladapter) do
  self.create_unlogged_tables = true
end

Unlogged tables: Postgres no escribe el WAL, el log que usa para recuperarse de un crash.
En CI, además: fsync, synchronous_commit y full_page_writes en off. Tip de @fatkodima ↗

−16 s−10%

Paso ocho: Postgres sin tupper. Postgres guarda todo pensando en que se puede cortar la luz: escribe un log, el WAL, para recuperarse de un crash. Pero los datos de test se tiran al terminar. No necesitan sobrevivir a nada. Con unlogged tables, Postgres se saltea ese log. En CI, que es un Postgres descartable, también apagamos fsync y compañía. El tip es de fatkodima. Ojo: aplica cuando se crea la tabla, así que hay que recrear las bases de test. 16 segundos, diez por ciento. ~20 s Si preguntan por fsync, synchronous_commit y full_page_writes (no hace falta decirlo en la charla): - fsync = off: Postgres le pide al sistema operativo que escriba, pero no espera a que los datos lleguen al disco. Si se corta la luz, la base puede quedar corrupta. - synchronous_commit = off: el COMMIT vuelve antes de que su registro del WAL esté en disco. Si hay un crash, se pierden las últimas transacciones confirmadas, pero la base no se corrompe. - full_page_writes = off: después de cada checkpoint, Postgres copia la página entera al WAL la primera vez que la modifica, para poder recuperarla si el disco la deja escrita a medias. Apagado, el WAL es más chico, pero una página a medio escribir no se puede reparar. - Las tres cambian seguridad ante crashes por velocidad. En producción, jamás. En el Postgres de CI, que es un contenedor que se tira al terminar el job, no hay nada que proteger. - Por qué solo en CI y no en la notebook: son configuraciones de todo el servidor, y el Postgres local también tiene las bases de desarrollo. Las unlogged tables, en cambio, solo afectan a las tablas de test. - Se complementan con las unlogged: la base principal de test sigue logged (db:test:prepare corre en development) y el catálogo de Postgres siempre escribe WAL. - Honestidad: su efecto en CI no lo medí por separado. - En GitHub Actions el contenedor de servicio no acepta flags, así que se aplican con ALTER SYSTEM y pg_reload_conf(). Ninguna necesita reiniciar.

Meme de Pikachu sorprendido: 'Postgres: menos trabajo. Benchmark: más lento. Yo:'

BloopersSe me quemó

El primer benchmark dijo que unlogged tables era más lento.

Ese paso corría sobre bases recién creadas: sin estadísticas, con la caché fría. Todos los demás usaban bases calientes.

No estaba midiendo la receta.
Estaba midiendo el horno.

Consejo de la abuelaPrecalentar el horno

Medí con el horno caliente.Bases ya creadas, con ANALYZE.
Alterná las variantes, y medí más de una vez.Misma configuración, dos corridas: 403 s y 202 s.
Chequeá que el cambio se haya aplicado.Revisé relpersistence antes de cada corrida.

Con el horno caliente: logged 168 s · unlogged 152 s

Y acá tengo una que preparé antes…

Suite completa, segundos de reloj, notebook con 4 núcleos. Cada barra suma un cambio a la anterior.

Original, un proceso

709

+ parallelize

259

+ bcrypt mínimo

215

+ 404 barata

188

− SimpleCov

169

− progress bar

161

− Bullet, log warn

158

+ unlogged tables

~142

5×más rápido

Doña Petrona decorando una torta de varios pisos, 1937 — la que preparé antes

En la cocina del restauranteCI con 2 CPUs

301 s

antes · mediana de 39 corridas

→

143 s

después · mediana de 3 corridas

2,1× en GitHub Actions. Con 2 procesos, paralelizar da 2× como máximo.
El resto lo ponen los otros ingredientes.

En una notebook con núcleos de sobra, los costos chicos casi no mueven el reloj.
En un runner con 2 CPUs, cada segundo de CPU ahorrado se nota.

¿Y en la cocina del restaurante? GitHub Actions, con dos CPUs. De 301 segundos a 143. Más del doble. Y acá está lo interesante: con dos procesos, paralelizar te da dos veces como mucho. Lo que pasa de dos lo ponen los cambios chiquitos. (Click.) En mi notebook, sacar Bullet o el log casi no movía el reloj, porque tenía núcleos de sobra. Pero el tiempo de CPU bajaba en cada paso. En un runner chico, ese CPU es tiempo de reloj. ~20 s Para explicar por qué importa el CPU aunque el reloj no se mueva (si preguntan, o si sobra tiempo): - Reloj y CPU miden cosas distintas. El reloj es cuánto esperás vos. El CPU es cuánto trabajo hizo la máquina, sumando todos los procesos. - Con workers en paralelo, el reloj lo marca el worker más lento y las esperas a Postgres. Si un worker termina antes, su núcleo queda libre y nadie lo aprovecha. Ahorrar CPU ahí no acorta la espera: la máquina trabaja menos, pero vos esperás lo mismo. - En la notebook: 4 núcleos, 8 hilos. Sacar el reporter, Bullet y el log bajó 142 segundos de CPU (753 → 611), y el reloj apenas se movió. - En CI con 2 CPUs no sobra nada: los dos workers y el propio Postgres se reparten esas dos CPUs. Cada segundo de CPU que sacás es casi un segundo menos de espera. Por eso en CI ganamos 2,1×, más que el 2× que da paralelizar. - Analogía de cocina: en una cocina con ocho hornallas, que una olla tarde un poco más no cambia la hora de la cena. Con dos hornallas, cada minuto de cada olla se suma. - Además: los minutos de CI se pagan, varios jobs comparten runner, y en la notebook ese CPU compite con el editor, el navegador y la batería. - Y el ahorro escala: cuando la suite crece o el runner es más chico, esa sobrecarga deja de esconderse.

Para llevarTips del chef

No estaba en los tests.Lo que más ganó fue configuración: una línea comentada, un costo de bcrypt, una página de error.

Medí cada cambio, más de una vez.Con el horno caliente y alternando. Si no, medís ruido.

Mirá el CPU, no solo el reloj.Lo que en tu notebook no se nota, en CI sí.

Lo que no puede fallar, solo cuesta.Coverage que nadie lee, un Bullet que no rompe, una barrita de progreso.

Sacale una foto 📸La receta entera

# test/test_helper.rb
parallelize(workers: :number_of_processors)
BCrypt::Engine.cost = BCrypt::Engine::MIN_COST

# config/environments/test.rb
config.consider_all_requests_local = false
config.log_level = ENV.fetch("RAILS_LOG_LEVEL", "warn")
ActiveSupport.on_load(:active_record_postgresqladapter) do
  self.create_unlogged_tables = true
end
Bullet.enable = true

# Gemfile
gem "simplecov"
gem "minitest-reporters"

¡Buen provecho!

¿Preguntas?

@fesilvajacquier

📦 Repo de la charla 📄 Artículo técnico

github.com/fesilvajacquier/test-perf-talk