Start from a concrete result#
Define the intended change: maximum hull, price, macro, button or real object. Parsing XML and flying a correctly equipped ship are different outcomes.
A single player verification sequence#
Check extension structure, IDs and dependencies; XML syntax and schema; import, patch and runtime logs; the actual game value or object; UI clicks, closing, refresh and reopening; then the same facts after a complete restart. XSD does not execute scripts. Research encountered constructs accepted by a schema but rejected by the MD parser.
Separate the scenarios#
For a property, check the effective value and conflicting patches. For a ship, check registration, appearance, equipment connections, flight and availability. For a setting, verify persistence and absence of repeated resets. New and saved objects may have different lifecycles.
Repeat expensive tests for a reason#
A button label change needs the affected UI check. Loadout or serialization changes need the relevant game scenario. Collect complete facts first, then compare all differences. One ship does not prove every hull class. Document exact conditions and untested cases; do not conceal a failure by manually repairing test assets. See logs, MD persistence and compatibility.