The test suite
IGL is meant to be implemented more than once. If only one program ever reads IGL files, then the language is in practice whatever that program happens to do, and the specification just follows along behind it. The test suite is there so it works the other way round: somebody writes an engine from the published documents, runs the suite, and the suite settles whether it agrees.
Nobody has to take the author's word for anything, mine included.
What it checks
Models that must be accepted, and models that must not
Fifty-six models IGL has to accept, and eighty-three it has to refuse. Each refusal also names the diagnostic message it must produce, so failing is not enough on its own: the engine has to fail for the right reason.
These models are taken from the examples in the specification itself, so the two cannot drift apart. If the specification changes and the tests are not rebuilt from it, the build stops right there. Otherwise the mismatch would sit quietly for six months and nobody would know.
A refusal case that does not name a message code is thrown out of the suite. A test that only says "this should fail" will pass on whatever the program complains about, including when it complains about the wrong thing, so it tells you very little.
Models with expected numbers
Fifteen models whose answers are known in advance. Every expected value was worked out by hand from the closed-form equation. None of them was recorded from a run: if you take the expected answer from the program you are testing, all you learn is that the program still agrees with itself.
Some models have no closed form. For those, the test states a property that has to hold instead, mass balance in a closed system for example. This catches a different kind of mistake, because an engine can get every single composition right and still lose mass along the way.
Checking your own engine
set IGL_ENGINE=C:\path\to\your-engine.exe run cargo test -p igl-conformance --test runtime -- --nocapture
With no engine configured, the suite says so and passes. A missing engine is not a fault in the language, and if the suite went red every time one is absent, people would soon stop paying attention to it.
One thing to watch: a run that measured nothing looks a lot like a run that measured everything. Read the count it prints at the end.
What passing does not mean
It means the engine agrees with the specification on the cases the suite covers. It does not mean the numbers are physically right, and it certainly does not mean that a fractionation factor is the one your study should be using. Those questions belong to the literature that the databases cite, and no test suite is going to settle them.