invariant means "something that should never changes". There are tests that, regardless of the account state, shall always be true.
the idea is to implement generic tests for any account. we could have a convention of a "account spec" and it could be as simple as implementing a function account => { ... tests here }
example:
function genericAccountInvariants (account, ctx) {
test("operations are in order", () => {
let dates = account.operations.map(o=>o.date);
let sorted = account.operations.sort(dateSorter);
expect(dates).toEqual(sorted);
});
if (ctx.stable) { // stable could be a flag that says "you can assume the account didn't change"
test("a sync works and do not change the operations list", async () => ...do a sync here... )
}
}each family could also provide their own invariant function to test the specific parts.
the point of this invariance definition is that we can now use it from different places and contextes! We can trivially use it for "stable" accounts that are frozen. but we can also use it in the bot. or we can use it inside LLD testing context. Basically as much as we will instrument it, more we will evaluate and detect problems.
NB: today, such tests already exists, a bit hidden in the "dataset test" logic, goal is to move out of this paradigm and make the dataset tests independent of the "frozen accounts", because these tests can be shared for the bot. making the "frozen dataset" pretty trivial as you can just compose the data with these invariants.
invariant means "something that should never changes". There are tests that, regardless of the account state, shall always be true.
the idea is to implement generic tests for any account. we could have a convention of a "account spec" and it could be as simple as implementing a function
account => { ... tests here }example:
each family could also provide their own invariant function to test the specific parts.
the point of this invariance definition is that we can now use it from different places and contextes! We can trivially use it for "stable" accounts that are frozen. but we can also use it in the bot. or we can use it inside LLD testing context. Basically as much as we will instrument it, more we will evaluate and detect problems.
NB: today, such tests already exists, a bit hidden in the "dataset test" logic, goal is to move out of this paradigm and make the dataset tests independent of the "frozen accounts", because these tests can be shared for the bot. making the "frozen dataset" pretty trivial as you can just compose the data with these invariants.