You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A non negligible amount of developers want to write their tests in clarity.
I wonder if this is something we could support "simply" by introducing a #[test] command processor.
It could look like:
I think we would still be using js/ts for coordinating / structuring the test execution, but at least the logic would be written in clarity - developers would be calling something like:
describe("Counter contract tests",()=>{it("ensures counter is counting",()=>{const{ result, events }=simnet.assertPublicFn("counter","test-increment",[Cl.uint(1)],deployer,);});});
So when deploying such contracts, I think the #[test] directive would exclude the subsequent clarity statement from the contract?
The text was updated successfully, but these errors were encountered:
Oh nice, that probably works. I guess with this present proposal, clarity testing clarity would become a first class citizen.
We can keep this issue open for a few week and passively collect feedbacks / demands?
A non negligible amount of developers want to write their tests in clarity.
I wonder if this is something we could support "simply" by introducing a
#[test]
command processor.It could look like:
I think we would still be using js/ts for coordinating / structuring the test execution, but at least the logic would be written in clarity - developers would be calling something like:
So when deploying such contracts, I think the
#[test]
directive would exclude the subsequent clarity statement from the contract?The text was updated successfully, but these errors were encountered: