Project

General

Profile

Actions

Feature #2460

open

unit testing via framework?

Added by Sweet Tea Dorminy 3 days ago. Updated 2 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
11/08/2026
Due date:
% Done:

0%

Estimated time:

Description

I've been missing the existence of easy unit testing a lot. tests/ has the shell checks (copyright, header guards, do the rulesets load), which are good integration checks. But there's nothing that would catch result_defense_bonus() scoring hills below grassland (#2454) or the cm solver quietly changing its answers -- my target for next weekend is speedup for cm solver.

I think there's a lot of potential to prevent future bugs by adding unit tests, although I know it can be a little tedious. May I propose the addition of Criterion (https://github.com/snaipe/criterion) as a library for unit testing, and then the habitual addition of unit tests as part of bugfixes?

I have no particular attachment to Criterion, but it has easy auto-registration of new tests, seems to be under active development, and minimal boilerplate. A whole test is:

    Test(combat, defend_bonus_monotone) {
      cr_assert_gt(defense_bonus_for(hills), defense_bonus_for(grassland));
    }

It also has parameterised tests, per-suite fixtures, runs each test in its own process so a crash is a red test rather than a dead run, and emits TAP that meson test reads. I think cmocka is another plausible choice, but I care more about automagic test discovery than I do about easy mocking; I'd rather have either than neither.

How I'd wire it in:

  • A meson feature option, tests, default auto. Without the library the build is unchanged.
  • Criterion from a distro package where there is one, otherwise as a meson subproject via a wrap in subprojects/. Criterion builds with meson; two of its own dependencies arrive through meson's cmake module, so the subproject route wants cmake at build time. Distro packages avoid that.
  • A fixture that loads a named ruleset headlessly and makes virtual players, cities and units on a small map. This is the real work, and it's framework-neutral: once it exists, a test of anything in common/ or the AI is a few lines.
  • The CI meson job runs meson test.
  • New issue tracker topic of tests

What I'd write first, all pure functions on virtual objects: combat power and win chance, requirement evaluation, actres_possible(), the cm solver against current behavior on small cities, and the AI site scoring. I'm happy to send the option, the fixture and the first dozen tests as the first patchset, with whichever library you'd prefer.

Thoughts?

Actions

Also available in: Atom PDF