Estrategias de Prueba para Aplicaciones Multi-Tenant en Laravel: Aislamiento de Esquemas con PostgreSQL

En el proyecto Reimpact/platform, nos enfrentamos al desafío de asegurar la robustez de nuestras pruebas, especialmente con la creciente complejidad de los entornos multi-tenant. Recientemente, el equipo implementó la funcionalidad de HasTenantTable, una característica crucial para el aislamiento de esquemas en bases de datos PostgreSQL, permitiendo que cada inquilino tenga su propio esquema de base de datos.

El Problema: Fallos en Pruebas de Homologación

Con la introducción de HasTenantTable, notamos que nuestras pruebas de homologación existentes comenzaron a fallar. La causa raíz era que los modelos ahora esperaban operar dentro de un esquema de inquilino específico, pero el entorno de prueba no estaba creando ni seleccionando estos esquemas antes de ejecutar las pruebas. Esto es un problema común cuando se trabaja con transacciones de base de datos en pruebas (DatabaseTransactions), ya que los cambios DDL (como la creación de esquemas) se revierten, impidiendo que los esquemas persistan para pruebas posteriores.

La Solución: Aislamiento con Conexiones DDL Separadas

Para resolver este problema, implementamos una estrategia donde la creación del esquema del inquilino se realiza a través de una conexión DDL separada. Esto garantiza que el esquema y las migraciones necesarias para el inquilino sobrevivan al rollback de DatabaseTransactions que ocurre al finalizar cada prueba. De esta manera, cada prueba se ejecuta en un entorno de inquilino aislado y correctamente configurado.

Además, como parte de estas actualizaciones y mejoras en la estructura de datos, se incluyó una migración para renombrar la columna homologated_from_sku a reference_sku en la tabla de productos, estandarizando los nombres de las columnas para una mayor claridad y consistencia.

Implementación Conceptual en Pruebas

Aunque el código específico puede variar, la idea general en un entorno de prueba de Laravel sería algo similar a esto:

namespace Tests\Feature;

use Illuminate\Foundation\Testing\RefreshDatabase;
use Illuminate\Support\Facades\DB;
use Tests\TestCase;

class ProductHomologationTest extends TestCase
{
    use RefreshDatabase;

    protected function setUp(): void
    {
        parent::setUp();

        // Asumimos un ID de inquilino para la prueba
        $tenantId = 'test_tenant'; 
        $schemaName = 'tenant_' . $tenantId;

        // Usar una conexión DDL separada para crear el esquema
        // Esto garantiza que el esquema persista fuera de la transacción de prueba principal
        DB::connection('ddl_connection')->statement("CREATE SCHEMA IF NOT EXISTS \"{$schemaName}\"");

        // Seleccionar el esquema para la conexión predeterminada para el resto de la prueba
        DB::statement("SET search_path TO \"{$schemaName}\", public");

        // Ejecutar migraciones específicas del inquilino si es necesario
        // $this->artisan('migrate', ['--database' => 'tenant_connection', '--path' => 'database/migrations/tenant']);

        // Aquí puedes realizar otras configuraciones, como crear datos de prueba
    }

    protected function tearDown(): void
    {
        $tenantId = 'test_tenant';
        $schemaName = 'tenant_' . $tenantId;

        // Limpiar el esquema después de las pruebas si es necesario
        DB::connection('ddl_connection')->statement("DROP SCHEMA IF EXISTS \"{$schemaName}\" CASCADE");

        parent::tearDown();
    }

    public function testProductHomologation(): void
    {
        // Ahora las pruebas se ejecutan dentro del esquema de inquilino correctamente configurado
        // ... tu lógica de prueba aquí ...
        $this->assertTrue(true);
    }
}

Este enfoque asegura que las pruebas para aplicaciones multi-tenant en Laravel sean robustas y fiables, manteniendo el aislamiento de datos esencial para cada inquilino.