A test checks a scenario you thought of, while model checking tries every order of actions and finds a rule violation nobody imagined. Test frameworks such as QUnit, Jest and Vitest check finished code on examples. Quint and TLA+ check the rules of a system even before any code exists, including code from an AI agent.
How Quint differs from QUnit: two similar names
QUnit is an engine for JavaScript tests, from the same family as Jest and Vitest. You write a function, then a test with an input and an expected answer, and the engine says whether they match. Quint is a language for describing how a system must behave. The program itself tries all possible moves and looks for those where a rule breaks. The mix-up comes from the name, while in essence these are programs of different classes. A comparison of the test engines themselves is in the article Jest vs Vitest vs QUnit.
What a QUnit test looks like. It takes a finished function, for example addition, feeds it one and two and compares the answer with three: assert.equal(add(1, 2), 3), an example from the QUnit site. If the answer is right, the test passes. All the test knows about the world is the input and the expected answer that you chose in advance.
A Quint model is built differently: there is no function and no answer in it. You describe which states the system can be in, which actions move it from one state to another and which rules must always hold. Quint itself runs such a model, simulates it and checks it before the code ships. So it does not matter whether the code is written: it checks the intent, not the implementation.
The table is best read row by row. The row "What it checks" shows the main difference: a test answers "does this function work correctly on this data", a model answers "is a situation that the rules forbid possible at all". A test is limited by what you thought up. A model is limited by what you put into it.
Quint or Jest and Vitest: what a test checks and what a model checks
A test engine finds an error on the inputs you thought up. If you did not think about two admins at once, no test about them gets written, and the error stays. A model works differently: it builds combinations of steps itself, including ones nobody thought of, and shows the first where a rule broke.
What a test catches well: an error in the function itself, for example a wrong discount calculation or a wrong date parse. The input is known in advance here, and the test quickly shows what broke. What a test misses: race conditions and other errors that appear only in a certain order of events. In practical examples this is how an admin login and logout overlapping in time and a crash in the middle of a meeting recording were found. Neither action is wrong on its own, so a test for each of them passes.
The weak spot of Quint is that it checks a model, not the code. If the model is described inexactly, it proves something about an imaginary system. So the model is checked against real cases that are already confirmed, and keep an "as is and as required" pair in it. More about this in the article about the models.
How Quint differs from TLA+ and Alloy
TLA+ and Alloy are formal languages of the same kind: in them you also describe rules and look for their violations. They are older than Quint and better covered in books. But the notation in TLA+ is mathematical, and a newcomer needs time to read it. Quint was designed as a more accessible notation for the same task: it looks like ordinary code, and engineers without a math background read it. A detailed comparison of all three languages is in the article TLA+ vs Alloy vs Quint.
What “the same programs” means. Quint can be checked by two programs: TLC and Apalache. TLC is the very first checking program for TLA+: it goes through states one by one, so for Quint it needs the model translated into TLA+. Such a search is predictable, but the world must be small.
Apalache is built into Quint: it translates the model into conditions and asks the Z3 solver. It can check chains only up to a given length, so its “ok” means “no violations within that length”. TLA+ is checked by the same two programs, while Alloy has its own analyzer. Besides checking, Quint has a quick random simulation: it looks for violations by sampling and does not prove that there are none.
Each of the three languages rests on its own idea. TLA+ is built on Leslie Lamport’s thought that the most precise way to describe a system is simple mathematics. Alloy describes evolving structures and a program for exploring them. Quint gives the same task in a notation engineers understand: the description can be run, simulated and checked before the code ships.
Maturity matters when heavy proofs are needed: large systems, strict guarantees for distributed protocols. The first version of the Alloy language appeared in 1997. TLA+ was created by Leslie Lamport, and according to Wikipedia the language dates to 1999. The Apalache checker was started in 2015, and the Quint repository was created in 2021, according to GitHub. So TLA+ has about 27 years of history and Quint about five.
Over those years TLA+ gathered books, courses and write-ups of real systems, while Quint has fewer. But the language develops fast: edits were pushed to the project repository on the day before the date of this article. For product rules like “a private recording never reaches shared storage” depth of proof is needed less often, and readability matters more.
What to choose: Quint, tests or TLA+
The choice is set by the question, not by a favorite program. If the question is "does this function work correctly", take a test. If the question is "can a rule break in some sequence of events", take a model. If you need guarantees at the level of a distributed protocol, take TLA+ and set aside time to learn it.
How they work together
In practice tests and models stand side by side. A test protects a specific function from breaking under edits. A model protects a rule that crosses several functions and depends on the order of events. When a model finds a chain of steps, a short regression test comes out of it: it fails on the old code and passes on the fixed one.
So the model hands the tests what it found, and the tests hold it in the code. A detailed account of the findings, the "as is and as required" pair and the checking of the checks is in the main article about Quint, and the context borders the models are written for are covered in the article about agents per context.
FAQ
QUnit runs tests of finished JavaScript code, while Quint describes the rules of a system and tries the orders of actions itself. The names are similar, but these are programs of different kinds.
They describe the same thing, and only the notation differs: Quint looks like ordinary code, while TLA+ uses mathematical notation. The same programs check both notations, TLC and Apalache.
If the question is whether a function works correctly, take a test. If it is whether a rule can break in some sequence of events, take Quint; for heavy proofs about a distributed system, people take TLA+.
Yes, they complement each other. A model finds the chain of steps where a rule breaks, and a short test pins it in the code so the error does not come back.