Cómo automatizar pruebas de regresión en el servidor de MU Online

Cada actualización en un servidor de MU Online — una nueva season, un evento personalizado, un ajuste de tasa de drop, una corrección de bug — carga el riesgo de romper algo que ya funcionaba. Es extremadamente común ver un servidor lanzar una corrección puntual y, sin darse cuenta, tumbar la Chaos Machine o impedir el login de una clase específica, descubriendo el problema recién cuando los jugadores se quejan en Discord. Este tutorial muestra cómo armar una suite de pruebas de regresión automatizadas que corre antes de que cualquier actualización vaya a producción, cubriendo los flujos más críticos del servidor: login, creación de personaje, drop, Chaos Machine y eventos.

Por qué las pruebas de regresión importan tanto en servidores privados

A diferencia de un software común, un servidor de MU Online tiene una característica particular: las "reglas de negocio" viven repartidas entre archivos de configuración (.txt, .xml, .ini), scripts de evento, base de datos y el propio binario del emulador. Un cambio pequeño en un archivo de configuración puede tener un efecto colateral en un sistema aparentemente no relacionado — por ejemplo, alterar la tasa de drop de un monstruo puede, por un error de tipeo, anular el drop de otro ítem en la misma línea. Las pruebas de regresión automatizadas existen justamente para detectar ese tipo de efecto colateral antes de que llegue a los jugadores.

Definiendo el alcance mínimo viable de la suite

No es necesario (ni realista) probar todo desde el inicio. Priorizá los flujos que, si se rompen, generan el mayor volumen de quejas y el mayor daño a la reputación del servidor:

Arquitectura de la suite de pruebas

El diseño recomendado separa las pruebas en capas, de la más rápida/barata a la más lenta/costosa, para correr las baratas con frecuencia y las costosas solo antes de los releases:

Pruebas de configuración (validación de sintaxis y consistencia)

La capa más barata y más valiosa: un script que valida si los archivos de configuración siguen teniendo el número de columnas esperado y si los valores críticos no quedaron fuera de rango, incluso antes de levantar el servidor:

import csv

def validar_item_txt(caminho, colunas_esperadas=25):
    erros = []
    with open(caminho, encoding='latin-1') as f:
        for i, linha in enumerate(f, 1):
            if linha.strip().startswith('//') or not linha.strip():
                continue
            campos = linha.split('\t')
            if len(campos) != colunas_esperadas:
                erros.append(f"Línea {i}: {len(campos)} columnas, esperado {colunas_esperadas}")
    return erros

erros = validar_item_txt("Data/Item/Item.txt")
if erros:
    print(f"FALLA: {len(erros)} inconsistencias encontradas")
    for e in erros[:10]:
        print(e)
else:
    print("OK: Item.txt consistente")

Pruebas de base de datos (schema y datos de referencia)

Después de una migración o actualización de emulador, es común que una tabla pierda una columna o que un valor de referencia cambie sin que nadie lo note. Una prueba simple de schema:

-- Verifica si las columnas críticas todavía existen después de una migración
SELECT COUNT(*) AS colunas_encontradas
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'Character'
  AND COLUMN_NAME IN ('Strength', 'Dexterity', 'Vitality', 'Energy', 'Level');
-- Esperado: 5

-- Verifica si los datos de referencia de clase/mapa no se corrompieron
SELECT COUNT(*) FROM MapInfo WHERE MapNumber BETWEEN 0 AND 10;
-- Esperado: un número conocido y estable

Pruebas vía comando de GM (sin necesitar el cliente gráfico)

Muchos emuladores exponen comandos administrativos vía la consola del servidor o el chat de GM que permiten probar flujos sin abrir el cliente completo — útil para automatización en CI:

# Pseudocódigo de prueba vía comando de GM (adaptar al protocolo real del emulador)
def testar_criacao_item(conexao_gm, tipo, indice, nivel):
    resposta = conexao_gm.enviar_comando(f"/make {tipo} {indice} {nivel}")
    assert "criado" in resposta.lower(), f"Falla al crear ítem {tipo}:{indice} — respuesta: {resposta}"

def testar_drop_monstro(conexao_gm, monstro_id):
    resposta = conexao_gm.enviar_comando(f"/killmob {monstro_id}")
    # Valida en el log/base de datos si se generó algún drop

Pruebas end-to-end con un bot simulando al jugador

Para los flujos más críticos (login, creación de personaje, entrada a un evento), conviene tener un bot que efectivamente se conecte y siga un guion fijo, validando el resultado esperado en cada etapa:

def teste_login_e_criacao_char(conta_teste, senha_teste):
    cliente = ClienteMuTeste(host="staging.miservidor.com", porta=44405)
    assert cliente.login(conta_teste, senha_teste), "El login falló"
    assert cliente.criar_personagem("TesteQA01", classe="DarkKnight"), "La creación de personaje falló"
    assert cliente.entrar_no_jogo(), "Falla al entrar al mundo con el personaje creado"
    cliente.desconectar()

Mantené una cuenta de prueba dedicada (qa_bot_01) separada de cuentas reales, reseteada en cada ejecución para no acumular estado entre pruebas.

Probando el flujo de la Chaos Machine

Como la Chaos Machine es uno de los flujos más sensibles a cambios de configuración (recetas, tasa de éxito), conviene una prueba dedicada que genere los ítems de entrada vía GM, intente la combinación y valide el resultado:

def teste_chaos_machine(conexao_gm, receita_id, itens_entrada):
    for item in itens_entrada:
        conexao_gm.enviar_comando(f"/make {item['tipo']} {item['indice']} {item['nivel']}")
    resultado = conexao_gm.enviar_comando(f"/testarcombinacao {receita_id}")
    assert resultado in ("sucesso", "falha_esperada"), f"Resultado inesperado: {resultado}"

Probando la entrada a eventos automáticamente

Reutilizando la lógica de lectura de estado de evento (ya usada en el pipeline de anuncio automático), es posible validar que el NPC de entrada del evento realmente mueva al personaje de prueba al mapa correcto:

def teste_entrada_devil_square(cliente_teste):
    cliente_teste.falar_com_npc("Devil Messenger")
    cliente_teste.selecionar_opcao("Entrar en Devil Square")
    mapa_atual = cliente_teste.obter_mapa_atual()
    assert mapa_atual == "Devias 2 (Evento)", f"Esperado Devias 2, obtenido {mapa_atual}"

Integrando la suite a un pipeline de CI

La mayor ganancia viene de correr la suite automáticamente cada vez que se altera una configuración en staging, antes de promoverla a producción. Un pipeline simple basado en script, sin depender de infraestructura compleja de CI:

#!/bin/bash
set -e
echo "1. Validando archivos de configuración..."
python3 testes/validar_configs.py

echo "2. Validando schema de la base de datos..."
mysql -u teste -p"$DB_PASS" mu_staging < testes/validar_schema.sql

echo "3. Ejecutando pruebas vía comando de GM..."
python3 testes/testes_gm.py

echo "4. Ejecutando pruebas end-to-end..."
python3 testes/testes_e2e.py

echo "Suite de regresión completada con éxito. Liberado para producción."

Si cualquier etapa falla (set -e interrumpe el script en el primer error), la promoción a producción debe bloquearse manualmente hasta que se corrija la causa.

Manteniendo un changelog de regresiones encontradas

Toda falla detectada por la suite (o, peor, que se le escape) debe documentarse: qué se rompió, por qué, y qué se corrigió. Esto evita que el mismo bug reaparezca silenciosamente en una actualización futura, y ayuda a priorizar qué nuevas pruebas agregar a la suite:

Errores comunes y soluciones

Lista de verificación de pruebas de regresión

• Alcance mínimo de flujos críticos definido y priorizado.
• Pruebas de configuración (sintaxis/consistencia) implementadas.
• Pruebas de schema/datos de referencia de la base de datos implementadas.
• Pruebas vía comando de GM cubriendo creación de ítem y drop.
• Prueba end-to-end de login y creación de personaje funcionando.
• Prueba de la Chaos Machine y de entrada a eventos automatizada.
• Pipeline de ejecución (script/CI) corriendo antes de cada promoción a producción.
• Changelog de regresiones encontradas mantenido y revisado.

Con la suite de regresión corriendo antes de cada actualización, cambiás el "cruzar los dedos para que no se haya roto nada" por una confirmación real antes de exponer el cambio a los jugadores. Si tu servidor todavía no tiene un entorno de staging separado de producción, ese es el siguiente paso natural — revisá el tutorial de creación de servidor de MU Online para estructurar esa separación correctamente.

Preguntas frecuentes