Unify our approach to testing contracts

[geoknee]

@andrewgordstewart and I investigated some problems I was having in ttt with flickering tests.

The following pattern:

apps/packages/rps/src/contract-tests/rock-paper-scissors.test.ts

Line 55 in 9f2ea6c

expect(validTransition(postFundSetupB, propose)).toBeTruthy();

can sometimes (often?) result in a promise being checked for truthy-ness, meaning that test will pass regardless of what the promise might resolve to. I fixed it in ttt:

apps/packages/tictactoe/src/contract-tests/ttt-game.test.ts

Line 54 in 9f2ea6c

expect(await validTransition(playing1, playing2)).toBe(true);

but something similar needs to be done in wallet and rps.

Furthermore, there is scope for folding this pattern as well as this one

apps/packages/tictactoe/src/contract-tests/ttt-game.test.ts

Line 87 in 9f2ea6c

await expect(tttContract.validTransition(encode(againMS), encode(againMF))).rejects.toThrowError("Could not match to a valid transition.");

, into a helper function in magmo-devtools which is the imported into the apps.

[andrewgordstewart]

Minor point of clarification:

[the expectation] can sometimes (often?) result in a promise being checked for truthy-ness

It always results in a promise being checked for truthyness. In the situations above, however, whateverContract.validTransition either resolves to true or throws an error, due to the implementation of the smart contract's validTransition function, so when an error isn't thrown, the test suite still isn't asserting that the returned value was true.

[andrewgordstewart]

as well as this one into a helper function in magmo-devtools which is the imported into the apps.

via something like

async function expectRevert(fn, msg) {
  expect.assertions(1);
  await expect(fn()).rejects.toThrowError(msg);
}

(this would replace magmo-devtool's assertRevert function, which does not interact well with jest tests)