Build a small regression test pack before changing your loot filter

A filter is easy to change and surprisingly easy to misunderstand. A small edit near the top can affect items matched much later, while a perfectly valid condition can express the wrong intention. Before a league start or another major change in your play plans, build a compact regression test pack. This is a set of representative items with written expected outcomes. It does not need to be enormous or automated to be useful. Its purpose is to make important assumptions visible before a mistake becomes difficult to notice during play.

Define what the test pack should protect

Begin with the decisions you would most regret getting wrong. These might include hiding an upgrade base, losing a clear highlight for an important resource, or applying an urgent sound to a very common drop. Write the expected behavior in ordinary language before writing any filter syntax. For each case, say whether the item should be visible and which parts of its presentation matter. A test with no stated expectation can confirm almost anything after the fact.

Keep the initial scope small enough that you will actually rerun it. A dozen thoughtful cases can be more useful than a large collection of unexplained copied items. Include examples from the categories you edited and a few stable categories you did not intend to change. Those stable cases act as controls: if they behave differently, the edit may have broader effects than expected. Expand the pack when you discover a real bug rather than collecting examples merely to increase its size.

Save raw evidence with each expectation

Store the copied item text exactly as obtained, together with the game and any context needed to interpret it. Do not silently normalize away a line that seems unimportant. That line may explain why a parser did not recognize the item or why a condition was unknown. If you edit a fixture to explore a hypothetical boundary, label it as a constructed example rather than presenting it as a real drop. Both kinds of examples are useful when their origin is clear.

A simple text note can record the case name, raw item, expected visibility, expected priority style, and reason. For instance, ‘personal weapon upgrade exception should override ordinary equipment hiding’ explains what the case protects. Avoid storing account details or unrelated chat text. The Item Tester processes supported inputs in the browser, but a file you later attach to a message or share elsewhere follows the privacy practices of that destination.

Test boundaries instead of only obvious matches

Suppose a condition uses a threshold. An example far above the threshold will not reveal whether you accidentally used a strict comparison instead of an inclusive comparison. Add values immediately below, exactly at, and immediately above the boundary where those values are meaningful. If the condition tests a string, add a similar name that should not match. These near-miss cases expose mistakes that a collection of obvious positive examples tends to overlook.

Do the same for combined conditions. A block whose conditions must all match should have a case that passes each condition except one. Vary the failed condition across a few cases. This helps reveal an unintended broad rule elsewhere or a mistaken belief that conditions are alternatives. Do not manufacture missing item properties inside the tester to force a result. If a required property is absent, preserve the unknown outcome and identify the evidence needed to resolve it.

Separate syntax checks from behavior checks

Run the Filter Validator before interpreting item results. A malformed block can make later analysis misleading, and a simple range error is easier to fix in isolation. Read warnings as well as errors. Some warnings identify unverified dependencies or features outside the tool’s supported subset rather than an instruction that is necessarily invalid. Record which warnings you accepted and why, instead of treating a smaller warning count as the objective.

Then evaluate each item against the candidate filter. A syntax pass means the checked text conforms to the implemented checks; it does not mean your intended item appears. Likewise, one successful item test does not validate every block. Maintain separate columns for syntax status, browser behavior result, and client observation. This prevents an attractive green result in one part of the workflow from being misreported as comprehensive compatibility testing.

Include rule-order and Continue cases

Filters are ordered programs, not unordered collections of preferences. Include at least one item that could match both a specific rule and a broader fallback. Write down which block should decide its visibility and why. If Continue is used, identify which later blocks should also be considered and which style actions are expected to survive. These cases are especially valuable after moving rules, because the text of each individual block may remain unchanged while the result changes.

Read the rule-order and Continue walkthrough if the expected path is unclear. Do not let the test tool choose the intended answer for you. The point is to compare implementation with a prior expectation. When unsupported semantics or unresolved imports could affect the path, mark the case as unresolved. An unknown result is a successful identification of a testing boundary, even though it is not a successful verification of the filter.

Check appearance as well as visibility

A visible item can still be effectively missed if its label is hard to read or its emphasis is inconsistent. Add a small visual review to priority cases: text legibility, background opacity, border distinction, and whether the label is recognizable without sound. Use the Color and Contrast Palette for preliminary contrast checks on several grounds. Its simulations and ratios help find weak combinations but do not certify the game’s rendering or every player’s perception.

Test sounds in the actual environment when they matter. A browser report cannot prove that a custom file exists in an arbitrary local directory, that the client can decode it, or that the chosen volume is comfortable during play. Keep the sound test separate from the syntax test. If you cannot perform it before the deadline, choose a simpler supported configuration or leave the limitation clearly recorded rather than claiming a full pass.

Compare a candidate with the known-good version

Save the previous working filter before editing and use a distinct candidate filename. The Filter Compare tool helps identify additions, removals, and changed lines. Review the diff alongside the test pack. Every intentional behavioral change should have an explanation, and every newly discovered defect should produce a regression case. A comparison can show that a block moved, but only your expectations and evaluation establish whether the move was appropriate.

Do not bury functional changes inside a large formatting cleanup immediately before a major play session. If you want to reorganize comments or spacing, do that separately and rerun the same cases. Small focused changes make failures easier to attribute and rollback safer. Keep the candidate even when it fails; its diff and failed case may be useful for understanding the mistake, as long as its filename clearly distinguishes it from the active working copy.

Finish with a real client check and a rollback plan

Follow the installation guide to place and select the candidate using controls available in your client. Confirm that the correct file loads, then observe representative items. A documentation review date is not a game patch verification date. Record the actual environment if you perform a client test, and avoid extending that result to platforms or modes you did not check. Keep the known-good file available throughout the session.

Your final note should distinguish passed, failed, and unresolved cases. If a high-impact case remains unresolved, choose a conservative fallback instead of hiding the uncertainty in a summary. After playing, add any unexpected behavior to the test pack while the evidence is fresh. Over time this creates a compact history of the decisions your filter must preserve. The benefit is not a promise of perfect filtering; it is a repeatable way to make changes with clearer evidence and fewer avoidable surprises.