This guide describes a test-oracle approach for the 18 regular types used by modern main-series Pokémon games. It deliberately keeps the scope narrow. Stellar is a special Tera Type and does not belong in the ordinary 18-by-18 base matrix. Pokémon GO and the trading card game use different systems. Abilities, items, Terastallization, terrain, weather and special move rules can also change what happens in an actual battle.

Start with direction, because direction is the commonest bug

A type chart is directional. “Fire is super effective against Grass” does not imply that “Grass is super effective against Fire.” A production application may store rows as attacking types and columns as defending types, or the other way around. A test fixture that uses the same orientation without checking it can reproduce the same mistake.

Write the test contract before writing code:

Given an attacking type and one or two defending regular types, return the product of the corresponding base defensive multipliers.

Then add a few unmistakable directional checks. Electric attacking Ground should be 0. Ground attacking Electric should be 2. Normal attacking Ghost should be 0, while Ghost attacking Normal should also be 0 for a different directional relationship. These checks reveal row/column reversals before a large suite hides the problem in hundreds of results.

Build an independent oracle

Do not import the application's chart object into its tests. If the application contains a wrong value, the test will happily confirm it. Instead, encode the reference relationships separately in the test project or generate them from an independently reviewed source file.

One compact representation stores only the non-neutral relationships for each attacking type:

const oracle = {
  electric: {
    water: 2,
    flying: 2,
    electric: 0.5,
    grass: 0.5,
    dragon: 0.5,
    ground: 0,
  },
  // Add the remaining attacking types independently.
};

function baseMultiplier(attack, defend) {
  return oracle[attack]?.[defend] ?? 1;
}

The important word is “independently.” A second object copied from the production file is duplication, not verification. Review the oracle row by row, keep its source and version visible, and make changes explicit in code review.

Exhaust the single-type matrix

With 18 regular attacking types and 18 regular defending types, the full single-type matrix contains only 324 cells. That is small enough to check exhaustively on every build.

for (const attack of TYPES) {
  for (const defend of TYPES) {
    const expected = baseMultiplier(attack, defend);
    const actual = appMultiplier(attack, [defend]);
    assert.equal(actual, expected, `${attack} -> ${defend}`);
  }
}

This catches isolated transcription errors, missing immunities, incorrect defaults and direction mistakes. It also gives a precise failure message instead of a vague “calculator is wrong” report.

Exhaust every unique dual type

For base type effectiveness, a dual-type defensive result is multiplication. If an attack is 2 against the first type and 2 against the second, the result is 4. If it is 2 against one and 0.5 against the other, the result is neutral 1. If either relationship is 0, the product is 0.

There are 153 unordered pairs of different types. Add the 18 single types and there are 171 single-or-dual defensive combinations. Across 18 attacking types, that creates 3,078 checks—still trivial for a build.

function oracleDual(attack, a, b) {
  return baseMultiplier(attack, a) * baseMultiplier(attack, b);
}

for (let i = 0; i < TYPES.length; i++) {
  for (let j = i + 1; j < TYPES.length; j++) {
    const a = TYPES[i];
    const b = TYPES[j];
    for (const attack of TYPES) {
      assert.equal(
        appMultiplier(attack, [a, b]),
        oracleDual(attack, a, b),
        `${attack} -> ${a}/${b}`
      );
    }
  }
}

This loop intentionally treats Water/Ground and Ground/Water as one defensive combination. Add a separate property test to confirm that reversing the two defending types never changes the result.

Add metamorphic properties

An oracle tells you the expected answer. Metamorphic tests verify relationships that must remain true even when you change the input.

Useful properties include:

1. Order independence: M(attack, A, B) = M(attack, B, A).
2. Single-type identity: adding a neutral relationship does not change the multiplier.
3. Immunity dominance: if either defensive relationship is zero, the combined base multiplier is zero.
4. Cancellation: 2 × 0.5 = 1 and 0.5 × 2 = 1.
5. Expected result set: single-type outputs belong to {0, 0.5, 1, 2}; dual-type outputs belong to {0, 0.25, 0.5, 1, 2, 4}.

These properties catch implementation errors that individual examples may miss. An addition bug can still produce plausible values for some combinations, but it will violate cancellation and the expected result set.

Test classification separately from arithmetic

Many interfaces group results into labels such as “4× weak,” “2× weak,” “neutral,” “resistant” and “immune.” Test the numeric multiplier first, then test the grouping layer separately.

This prevents a display bug from being confused with a chart bug. A correct value of 0.25 placed under a 0.5× heading is a presentation failure. A wrong value of 0.5 is a calculation failure. They need different fixes.

Also test that every attacking type appears exactly once across the displayed groups. Missing and duplicated types can survive numeric unit tests if the rendering code filters incorrectly.

Keep battle mechanics outside the base oracle

The base matrix should remain boring. Do not quietly add an ability, held item, move exception or Tera state to the same function and then call its output “type effectiveness.” Create a separate rule layer with explicit inputs.

For example, Freeze-Dry has a special interaction with Water-type targets. Flying Press has unusual type-effectiveness handling. Levitate can change a Ground interaction. Those rules do not mean the underlying Ground/Flying or Ice/Water matrix cells should be rewritten.

This separation also explains the scope to users. TypeWeakness presents the 18-regular-type base matrix for modern main-series games and documents that special mechanics may change a battle result. A verification suite should preserve that same boundary rather than claiming to simulate every battle system.

Make failures useful

A good failure should show:

• attacking type;
• defending type or pair;
• expected multiplier;
• actual multiplier;
• oracle version or source revision;
• whether the failure occurred in arithmetic or display classification.

When a game update or data-source change requires review, this information makes the change auditable. Do not automatically overwrite the oracle from the production source to make a failing build green. Investigate which side is wrong.

Run the small exhaustive suite on every build

This is one of the rare domains where exhaustive testing is simpler than clever sampling. Three thousand and seventy-eight base checks are tiny. Add validation for input names, duplicate types, unknown values and result-group coverage, and the suite still finishes quickly.

The strongest confidence does not come from a long list of hand-picked Pokémon. It comes from a separately constructed oracle, complete matrix coverage, every unique dual type, and explicit scope boundaries. That structure makes a calculator easier to trust because each conclusion can be traced to a small, testable rule.