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

Export Internal Testing Tools #2065

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from
Draft

Export Internal Testing Tools #2065

wants to merge 7 commits into from

Conversation

boray
Copy link
Member

@boray boray commented Feb 26, 2025

This PR exposes existing internal testing tools for use of third party primitive developers.

Changes:

  • Created aTesting namespace in src/lib/testing/testing.ts that organizes the testing tools.
  • Testing namespace is exported from Experimental.
  • Added an example in src/examples/testing.ts to demonstrate the use of Testing utilities.

Copy link
Contributor

@mitschabaude mitschabaude left a comment

Choose a reason for hiding this comment

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

So a problem seems to be that the testing framework relies on Nodejs imports, and this isn't compatible with the web version.

On the other hand, o1js is designed to work in all JS runtimes.

I think for this reason it would be cleaner to export the testing framework as a separate package or package entry-point, like we already do with mina-signer.

This is a general direction we always wanted to move in: Have separate entry-points like o1js/light, o1js/prover and o1js/testing with different levels of functionality

external: ['*.bc.js'],
external: ['*.bc.js', 'node:assert/strict'],
Copy link
Contributor

Choose a reason for hiding this comment

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

this breaks the web version doesn't it?

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, I wasn't sure how acceptable is this since testing tools won't be used in web but it still breaks the web version.

Comment on lines -40 to +43
let { constraintSystemSync } = await synchronousRunners();
let constraintSystemSync: any;
(async () => {
constraintSystemSync = await synchronousRunners();
})();
Copy link
Contributor

Choose a reason for hiding this comment

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

how is this supposed to work? to me it seems to impose an ugly implicit assumption that bindings are initiated before using the testing framework. this should be made explicit

Copy link
Member Author

Choose a reason for hiding this comment

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

this doesn't work. I was testing this to prevent having a top-level await.


export { Testing };

namespace Testing {
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't like how you pack unqualified names like or and bool, that have nothing to do with each other, into a flat namespace. why not export three namespaces?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't like either. I am just experimenting for now.

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

Successfully merging this pull request may close these issues.

2 participants