Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: add complete tests around abi-contract program #3246

Closed
wants to merge 37 commits into from

Conversation

petertonysmith94
Copy link
Contributor

Part of TS-599

Summary

  • We've added a feature complete contract (abi-contract) that taking in fixed inputs, and returns an expected value.
    • We did as @nedsalk mentioned that Sway does some precompiling.
  • We have added tests for each of the functions of the contract, currently using our current encoding package @fuel-ts/abi-coder.
    • This will allow us to switch out the Interface for our new refactored package with absolute certainty of no regression.
  • I have added a new custom vitest matcher toEqualBn to make it easier to check returned BN values.

Couple issues

  • For the custom vitest matchers, I struggled to get this working with TS so have added a TS ignore (// @ts-expect-error: Custom matcher 'toEqualBn') for now.
  • I was getting some odd results from some functions whereby the inputs we're being returned as the outputs. These are marked as (Most of these are suffering from the similar issue around returning the input as the output.)

Checklist

  • All changes are covered by tests (or not applicable)
  • All changes are documented (or not applicable)
  • I reviewed the entire PR myself (preferably, on GH UI)
  • I described all Breaking Changes (or there's none)

@petertonysmith94 petertonysmith94 added the chore Issue is a chore label Oct 3, 2024
@petertonysmith94 petertonysmith94 self-assigned this Oct 3, 2024
Copy link

vercel bot commented Oct 3, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
fuels-template ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 7, 2024 1:06pm
ts-api-docs ❌ Failed (Inspect) Oct 7, 2024 1:06pm
ts-docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 7, 2024 1:06pm

Comment on lines +1 to +20
import { bn } from 'fuels';
import type { BNInput } from 'fuels';

export const toEqualBn = (_received: BNInput, _argument: BNInput) => {
const received = bn(_received);
const argument = bn(_argument);

const pass = received.eq(argument);

if (pass) {
return {
message: () => `Expected ${received.toString()} not to equal ${argument.toString()}`,
pass: true,
};
}
return {
message: () => `expected ${received.toString()} to equal ${argument.toString()}`,
pass: false,
};
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nedsalk said this wasn't going to go down well with the team

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The annoying (ugly) part of adding these custom assertions is usually making TS aware of them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nedsalk said he'd sort this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@arboleya are you happy with the Vitest matcher, or would you favour a standalone function?

@petertonysmith94
Copy link
Contributor Author

We're experiencing a stack overflow (related Sway issue)

* @group node
*/
describe('AbiCoder', () => {
let contract: AbiContract;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd favor creating a setupContract() helper like here and using it in every test instead of reusing the same contract/node across all tests.

using contract = await setupContract();

There's nothing wrong with the approach you've taken here given that all these calls are read-only, but if we decide to parallelize these tests in the future we'll have to do the setupContract approach or we'd be getting issues related to already spent coins. It's better to just have a hard rule of always spinning up a node for every test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I favour this also - just used this approach for speed of development.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Issue is a chore
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants