-
Notifications
You must be signed in to change notification settings - Fork 145
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this 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'], |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
let { constraintSystemSync } = await synchronousRunners(); | ||
let constraintSystemSync: any; | ||
(async () => { | ||
constraintSystemSync = await synchronousRunners(); | ||
})(); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
This PR exposes existing internal testing tools for use of third party primitive developers.
Changes:
Testing
namespace insrc/lib/testing/testing.ts
that organizes the testing tools.Testing
namespace is exported fromExperimental
.src/examples/testing.ts
to demonstrate the use ofTesting
utilities.