How to automate regression testing on your MU Online server

Every update on a MU Online server — a new season, a custom event, a drop rate tweak, a bug fix — carries the risk of breaking something that already worked. It's extremely common to see a server ship a targeted fix and, without noticing, break the Chaos Machine or block login for a specific class, only discovering the problem from players complaining on Discord. This tutorial shows how to build an automated regression testing suite that runs before any update goes to production, covering the server's most critical flows: login, character creation, drops, Chaos Machine, and events.

Why regression tests matter so much on private servers

Unlike typical software, a MU Online server has a particular trait: its "business rules" live scattered across configuration files (.txt, .xml, .ini), event scripts, the database, and the emulator binary itself. A small change in a configuration file can have a side effect on a seemingly unrelated system — for example, changing a monster's drop rate can, by a typo, zero out the drop of another item on the same line. Automated regression tests exist precisely to catch this kind of side effect before it reaches players.

Defining the suite's minimum viable scope

It's not necessary (or realistic) to test everything from the start. Prioritize the flows that, if broken, generate the most complaints and the most damage to the server's reputation:

Suite architecture

The recommended design splits tests into layers, from fastest/cheapest to slowest/most expensive, so the cheap ones run frequently and the expensive ones only run before releases:

Configuration tests (syntax and consistency validation)

The cheapest and most valuable layer: a script that checks whether configuration files still have the expected number of columns and that critical values haven't fallen out of range, even before the server starts:

import csv

def validate_item_txt(path, expected_columns=25):
    errors = []
    with open(path, encoding='latin-1') as f:
        for i, line in enumerate(f, 1):
            if line.strip().startswith('//') or not line.strip():
                continue
            fields = line.split('\t')
            if len(fields) != expected_columns:
                errors.append(f"Line {i}: {len(fields)} columns, expected {expected_columns}")
    return errors

errors = validate_item_txt("Data/Item/Item.txt")
if errors:
    print(f"FAILED: {len(errors)} inconsistencies found")
    for e in errors[:10]:
        print(e)
else:
    print("OK: Item.txt is consistent")

Database tests (schema and reference data)

After a migration or emulator update, it's common for a table to lose a column or a reference value to change without anyone noticing. A simple schema test:

-- Checks whether critical columns still exist after a migration
SELECT COUNT(*) AS columns_found
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'Character'
  AND COLUMN_NAME IN ('Strength', 'Dexterity', 'Vitality', 'Energy', 'Level');
-- Expected: 5

-- Checks whether class/map reference data hasn't been corrupted
SELECT COUNT(*) FROM MapInfo WHERE MapNumber BETWEEN 0 AND 10;
-- Expected: a known, stable number

Tests via GM command (no graphical client needed)

Many emulators expose admin commands via the server console or GM chat that let you test flows without opening the full client — useful for CI automation:

# Pseudocode for a test via GM command (adapt to your emulator's real protocol)
def test_item_creation(gm_connection, item_type, index, level):
    response = gm_connection.send_command(f"/make {item_type} {index} {level}")
    assert "created" in response.lower(), f"Failed to create item {item_type}:{index} — response: {response}"

def test_monster_drop(gm_connection, monster_id):
    response = gm_connection.send_command(f"/killmob {monster_id}")
    # Validate in the log/database whether a drop was generated

End-to-end tests with a bot simulating the player

For the most critical flows (login, character creation, event entry), it's worth having a bot that actually connects and plays a fixed script, validating the expected result at each step:

def test_login_and_character_creation(test_account, test_password):
    client = MuTestClient(host="staging.myserver.com", port=44405)
    assert client.login(test_account, test_password), "Login failed"
    assert client.create_character("QATest01", char_class="DarkKnight"), "Character creation failed"
    assert client.enter_world(), "Failed to enter the world with the created character"
    client.disconnect()

Keep a dedicated test account (qa_bot_01) separate from real accounts, reset on every run so state doesn't accumulate between tests.

Testing the Chaos Machine flow

Since the Chaos Machine is one of the flows most sensitive to configuration changes (recipes, success rate), it's worth having a dedicated test that generates the input items via GM, attempts the combination, and validates the result:

def test_chaos_machine(gm_connection, recipe_id, input_items):
    for item in input_items:
        gm_connection.send_command(f"/make {item['type']} {item['index']} {item['level']}")
    result = gm_connection.send_command(f"/testcombination {recipe_id}")
    assert result in ("success", "expected_failure"), f"Unexpected result: {result}"

Testing event entry automatically

Reusing the event-state-reading logic (already used in the automatic announcement pipeline), you can validate that the event entry NPC really moves the test character to the correct map:

def test_devil_square_entry(test_client):
    test_client.talk_to_npc("Devil Messenger")
    test_client.select_option("Enter Devil Square")
    current_map = test_client.get_current_map()
    assert current_map == "Devias 2 (Event)", f"Expected Devias 2, got {current_map}"

Integrating the suite into a CI pipeline

The biggest payoff comes from running the suite automatically every time a configuration is changed in staging, before promoting to production. A simple script-based pipeline, without depending on complex CI infrastructure:

#!/bin/bash
set -e
echo "1. Validating configuration files..."
python3 tests/validate_configs.py

echo "2. Validating database schema..."
mysql -u test -p"$DB_PASS" mu_staging < tests/validate_schema.sql

echo "3. Running GM command tests..."
python3 tests/gm_tests.py

echo "4. Running end-to-end tests..."
python3 tests/e2e_tests.py

echo "Regression suite completed successfully. Cleared for production."

If any step fails (set -e stops the script on the first error), promotion to production should be manually blocked until the cause is fixed.

Keeping a changelog of regressions found

Every failure caught by the suite (or, worse, missed by it) should be documented: what broke, why, and what was fixed. This prevents the same bug from silently resurfacing in a future update, and helps prioritize which new tests to add to the suite:

Common errors and fixes

Regression testing checklist

• Minimum scope of critical flows defined and prioritized.
• Configuration tests (syntax/consistency) implemented.
• Schema/reference data database tests implemented.
• GM command tests covering item creation and drops.
• End-to-end login and character creation test working.
• Chaos Machine and event entry test automated.
• Execution pipeline (script/CI) running before every production promotion.
• Regression changelog maintained and reviewed.

With the regression suite running before every update, you trade "hoping nothing broke" for actual confirmation before exposing the change to players. If your server doesn't yet have a staging environment separate from production, that's the natural next step — review the MU Online server creation tutorial to set up that separation correctly.

Frequently asked questions