Testing & Contribution

Testing & Contribution

TLDR

• test in the supported local workflow, not a shortcut
• test the layer you changed and at least one meaningful edge case
• use the 1.3.8 regression checklists for blasters, themes, starships, and power bonuses when relevant
• include enough context that a reviewer can tell what changed, what was rebuilt, and what was actually tested

This page explains how to test changes responsibly and how to contribute to the SW5e Module in a way that respects the project’s workflow.

If you are making code changes, editing source compendium data, adjusting templates, or helping refine the module’s behavior, this page is meant to keep your work disciplined. The goal is not just to “make it work on your machine.” The goal is to make changes that are easier to review, safer to merge, and less likely to break existing content or active campaigns.

Who this page is for

Use this page if you are:

• changing runtime behavior in scripts/
• editing templates, styles, or localization for user-facing behavior
• modifying source compendium content in packs/_source
• touching migration, normalization, or compatibility-sensitive code
• preparing a bugfix, feature contribution, or content correction for review

If you only want to create homebrew content for your own game, use Homebrew and Content Authoring instead.

The most important rule

Test the kind of thing you changed, in the environment the project expects, using the project’s supported workflow.

That means good testing is not just “open Foundry and click around.” It starts with:

• using the supported Foundry and DND5e versions
• editing the real source-of-truth location
• rebuilding the right layer when needed
• checking both the normal path and at least one nearby edge case

What counts as “tested”

A change is not really tested just because:

• the world loaded once
• one happy-path click succeeded
• a template rendered without obvious errors

A change is closer to “tested” when you have checked:

• the intended success case
• at least one realistic edge case or failure-adjacent case
• whether the change affects older or migration-sensitive content
• whether the visible UI and the actual runtime behavior both match expectations

Baseline contributor workflow

A safe contribution workflow looks like this:

1. identify the feature area and likely layer first
2. edit the source-of-truth location, not a generated artifact
3. rebuild generated output if the change affects source content or LESS
4. test in a local Foundry environment that matches the expected versions
5. test both the primary success case and one or more meaningful edge cases
6. note anything migration-sensitive, compatibility-sensitive, or still untested before handing the change off

Match your tests to the layer you changed

If you changed localization, labels, or terminology

Test that:

• the right labels appear in the right places
• nothing falls back to outdated terminology unexpectedly
• the change appears on all relevant surfaces, not only one obvious screen

If you changed templates, sheet layout, or styling

Test that:

• the correct data is present in the template context
• the layout works in the expected sheet mode or actor state
• the UI still behaves correctly when editing, not just when reading
• the visual change did not hide or break a control that still matters at runtime

If you changed runtime patch logic

Test that:

• the expected behavior works in play, not just in data prep
• the relevant actor or item types are actually exercising the new path
• a nearby workflow was not accidentally broken by the patch

If you changed source compendium data

Test that:

• the change was made in packs/_source, not only in built output
• the pack rebuild completed successfully
• the built result is correct in Foundry, not just in source JSON
• references, images, types, and labels still resolve correctly after build

Regression checklists for major 1.3.8 feature areas

These are the most support-heavy areas to smoke test when relevant.

Blaster reload and ammo UX

Check at least:

• a supported managed blaster shows the Reload control on the weapon row
• Attack at 0 ammo produces the private Reload card
• Rapid or Burst with partial ammo produces the “not enough ammo” path
• reloading consumes compatible inventory ammo
• successful reload refills the magazine
• a normal successful use still consumes shots as expected

Appearance and branding after theme removal

Check at least:

• stock Foundry Light/Dark chrome on supported sheets
• retained Pause branding, lightsaber headers, and logos
• a representative actor or item sheet
• a representative dialog or configuration app
• that stale theme-mode settings are ignored if present on older worlds

Starship System Damage, Destruction Saves, and status sync

Check at least:

• the current Core | Inventory | Features | Effects | Description layout
• System Damage display and sidebar state
• Destruction Save tray behavior at Hull 0
• starship condition controls
• token HUD icon sync for Used, Slowed, Cover, and System Damage

Power attack and save DC bonus effects

Check at least:

• a Force power attack bonus case
• a Tech power attack bonus case
• a broad power DC bonus case
• an ability-specific or save-target DC bonus case
• any Configure Powercasting or override-driven edge case affected by the change

Test fresh content and older content when it matters

The project has real migration and normalization history.

So if your change touches:

• structure
• item types
• module IDs or paths
• compendium references
• starships
• copied world content

test both:

• a freshly created or freshly imported example
• and an older or migrated example when possible

If you only test new content, you may miss the hardest part of the problem.

A good regression mindset

One of the best habits a contributor can build is to stop asking only:

• “Did I fix my bug?”

and start asking:

• “What else uses this path?”
• “What old content depends on this assumption?”
• “What helper or normalization path is protecting me from a legacy problem?”

What to include with a contribution

When you hand off a fix, open an issue, or prepare a change for review, include enough context that someone else can understand what you did without guessing.

At minimum, include:

• what feature area you changed
• what files or layers were edited
• whether source content or styles were rebuilt
• what environments or versions you tested against
• what you tested manually
• whether you checked any older or migrated content
• what remains untested or uncertain, if anything

Good bug reports and change requests

A good report usually includes:

• exact Foundry, DND5e, and SW5e Module versions
• whether the issue affects one document or many
• whether the affected content is fresh, older, or migrated
• steps to reproduce the problem clearly
• whether a known-good built-in example behaves the same way or not

That is much more useful than “this broke.”

Contribution habits that help maintainers

These habits make contribution easier to review:

• keep changes scoped when possible
• avoid editing generated artifacts unless the workflow explicitly requires it
• do not reintroduce hardcoded module-ID or old-path assumptions the repo already worked to remove
• call out migration-sensitive consequences early if your change touches content structure or references
• mention if your fix depends on a specific version assumption or prerelease environment

Related pages

Use these pages next depending on what you need:

• Developer Guide for the broader contributor workflow
• Developer Reference for quick lookup while working
• Local Setup and Workflow for rebuild and reload rules
• Troubleshooting if you are approaching the problem from the user symptom side
• Compatibility & Limitations if you need to think through version and migration boundaries