test: initial stab at trying Ava test framework #1447
Conversation
…worked for new synchronous mint still
- `getInviteIssuer` to `getInvitationIssuer` - `inviteDesc` to `description`
zcf.addEmptySeat() would return a zcfSeat that the contract could use to hold allocations. untested
drop keyword parameter in addEmptySeat() extract makeZoeSeatAdminKit, use it for emptySeat, too. rename zcf seat construction to use 'Kit'
refactor: add types to reveal the wallet changes needed for Zoe
improved type annotations rename makeEmptySeat to makeOfferlessSeat don't return the zcfSeatAdmin to the contract
feat: add the ability for a contract to get a synchronous seat
fix: make Zoe typesafe again
Based on the synchronous seat work. The unit tests for autoswap pass. I haven't yet done the swingset tests.
refactor: bring autoswap up to date on the new Zoe spike branch
Repair autoswap
chore: add hasExited, getNotifier to UserSeat
* chore: update tests * chore: finish automaticRefund tests * chore: update barterExchange and brokenContract tests. Small changes to Zoe and types (#1427)
fix: get wallet tests to pass with new Zoe API
Just to be clear, this wasn't approval. It is happy enthusiasm. |
| return E(issuer) | ||
| .burn(payment1, amountMath.make(837)) | ||
| .then(burntBalance => { | ||
| t.ok( | ||
| t.assert( | ||
| amountMath.isEqual(burntBalance, amountMath.make(837)), | ||
| `entire minted payment was burnt`, | ||
| ); | ||
| t.rejects(() => issuer.getAmountOf(payment1), /payment not found/); | ||
| return t.throwsAsync(() => issuer.getAmountOf(payment1), { message: /payment not found/ }); | ||
| }) | ||
| .catch(e => t.assert(false, e)); | ||
| }); |
There was a problem hiding this comment.
t.notThrows() would be good here.
There was a problem hiding this comment.
Would our rule be to put t.throwsAsync or t.notThrows (t.notThrowsAsync??) around every call that returns a Promise? I can't imagine us being ok with any potential rejection going unnoticed, so every promise would fall into one of:
- we expect a positive result and want to examine it: use
checkResult(await ..)ort.notThrows(..).then(checkResult) - we expect a positive result but don't care about the value: use
await ..ort.notThrows(..); - we expect a negative result (testing delibrary failure situations): use
t.throwsAsync(..);
For sync stuff, I expect an exception that throws high enough to be noticed by the enclosing test case to flunk the test. As long as any lower-level exceptions cause a Promise to reject, and we don't drop any promises on the floor inside our libraries, and our test cases are on the lookout for rejections, then arbitrary exceptions in our libraries ought to make the test cases flunk too.
re #1335
A spike to see how AVA test frameworks. See #1335 for discussion.
Only ERTP tests were completely converted, though many tests required no additional changes to pass.