Replies: 9 comments 21 replies
-
|
To understand all options here: Is there a way to keep deno out of the final binary, say by compiling a separate version that's only used for development installs & testing ( |
Beta Was this translation helpful? Give feedback.
-
|
I don't think so. Deno is fully part of the final product, it's used by Clarity developers to execute the Clarity tests |
Beta Was this translation helpful? Give feedback.
-
I think it's a safe assumption (and we can test it if needed) that the vast majority of developers using |
Beta Was this translation helpful? Give feedback.
-
|
@lgalabru: What would it mean for existing Clarinet-generated projects if we migrated to Node? Assuming you'd gracefully handle migrating them over in a backward-compatible manner, I wanted to check how/if this would disrupt any existing setup. |
Beta Was this translation helpful? Give feedback.
-
|
It would be pretty disruptive, we could keep the same testing API, but a lot of things like imports etc would change. |
Beta Was this translation helpful? Give feedback.
-
|
It does look like a major upgrade. But we could include a Codemod to make things easier |
Beta Was this translation helpful? Give feedback.
-
|
This comes with a cost (or rather costs) as you'll now have to educate the users of the software on how they can migrate their tests. And you can't really touch existing tests; you'll make them less trustworthy. So Deno tests MUST still be able to run. Deno has a built-in test discovery mechanism. Node.js doesn't. A problem to be solved. On the other hand, if you switch to Node you'll make the integration with fuzzing and property tests a whole lot easier. Happy to discuss this in very detail. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting insights, thanks for sharing.
The way I see it is that developers will be able to tests smart contracts with existing technologies and the test frameworks they already know. (You could test smart contract with the same framework as a frontend application like mocha or jest). Instead of learning clarinet test
I don't understand what you mean by that, could you briefly elaborate? |
Beta Was this translation helpful? Give feedback.
-
The question is, should Clarity developers think in or into the Clarity language? That was one of the reasons behind the success of foundry on Ethereum; it minimizes the context switching between Solidity and JS/TS and focus on what matters most1 (the smart contract language). IMHO, the direction that @igorsyl, @jo-tm, @sergey-shandar, are taking in sBTC is the way to go; tests are written in Clarity, and discovered and run via Clarinet using Deno. That way, in sBTC, they get almost for free the ability to do Invariant Testing, and adding support for property tests (and fuzz tests afterwards) won't require any change inside Clarinet, Deno, (or Node.js in this case). 1Because (non-upgradable) smart contracts are like hardware devices; once they're shipped they can't really be changed. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @igorsyl @moodmosaic, I'll try to clarify the context: What is the issue and why addressing it now
Solution(s)
@igorsyl |
Beta Was this translation helpful? Give feedback.
-
@hugocaillard : Agreed, I think a discussion in the stacks-blockchain repo is needed. |
Beta Was this translation helpful? Give feedback.
-
|
@hugocaillard, thank you for the above detailed points 👍
That's a rather expensive tradeoff 🤔 (OTOH, security also relies on best practices, code quality, and how the software is maintained.) Perhaps, if you decide to use Node.js you could maintain the original Clarinet/Deno syntax |
Beta Was this translation helpful? Give feedback.
-
|
@moodmosaic
Yes exactly, this is what I call the |
Beta Was this translation helpful? Give feedback.
-
|
Sounds good to me, then. |
Beta Was this translation helpful? Give feedback.
-
IMHO, existing tests written in Deno and TypeScript must run without modifications, even if you decide to switch to Node.js, because:
|
Beta Was this translation helpful? Give feedback.
-
|
The idea of writing clarity for testing clarity is not new, believe me I thought about it and gave it a try. With this workstream, we want to start from a blank slate, and based on what we learned, bring smart contract testing to the next level both in terms of methodology and tooling - and I'm certain that fuzz testing is a piece of the puzzle. Foundry is successful today because before Foundry, there was Truffle and Hardhat. This ecosystem matured and competition pushed boundaries, with new approaches being started from scratch. |
Beta Was this translation helpful? Give feedback.
-
|
With language versioning clearly defined on the code level (stacksgov/sips#95 (comment)) you would be able to define your own language version ie. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @LNow, |
Beta Was this translation helpful? Give feedback.
-
|
If you have clarity version defined within the contract, you can define your own syntax for testing purpose. You can do it for simple unit-tests, fuzz-test, prop-based-test. Contract named (clarity-version "2.1")
(define-data-var counter uint u0)
(define-constant DEPLOYER tx-sender)
(define-public (increment (by uint))
(begin
(var-set counter (+ (var-get counter) by))
(stx-transfer? u200 tx-sender DEPLOYER)
)
)Tests: (clarity-version "clarinet-2.1")
;; `test` - custom function that describes single test
;; (test (test-name) test-body)
(test (check-increment)
(let (
(sender1 'ST1SJ3DTE5DN7X54YDH5D64R3BCB6A2AG2ZQ8YPD5)
(sender2 'ST2JHG361ZXG51QTKY2NQCVBPPRRE2KZB1HR05NNC)
(by u20)
;; `call-public` - another custom function, this time to define call of a public function
(tx1 (call-public sender1 counter-contract increment by))
(tx2 (call-public sender2 counter-contract increment by))
;; `mine-block` - another custom function; returns a tuple: { height: uint, receipts: (list receipt)}
;; where `receipts` is another tuple: { result: (response X Y), events: (list event)}
(block (mine-block (list tx1 tx2)))
)
(asserts! (is-eq ((get height block)) u17) (err "Invalid block height"))
(asserts! (is-eq (len (get receipts block)) u2) (err "invalid number of receipts"))
;; `[x]` syntax could be defined as shortcut for `(unwrap-panic (element-at list X))`
(asserts! (is-ok (get result (get receipts block)[0])) (err "Should succeed"))
(asserts! (is-err (get result (get receipts block)[1])) (err "Should fail"))
(asserts! (is-eq
(get events (get receipts block)[0])[0]
{type: "stx-transfer", from: sender1, to: 'ST1PQHQKV0RJXZFY1DGX8MNSNYVE3VGZJSRTPGZGM, amount: u200})
(err "invalid event"))
(asserts! (is-eq (len (get events (get receipts block)[1])) u0) (err "Failed transaction can't have events"))
)
)Above is just an example. You could define functions which allows you to access maps and variables without exposing them with read-only or public functions. |
Beta Was this translation helpful? Give feedback.
-
|
This could be an interesting addition to the sBTC Mini protocol tests which are written in Clarity (and discovered and executed by Clarinet). |
Beta Was this translation helpful? Give feedback.
-
|
In the clarinet.toml you can already specify which clarity version to use for each contract, so from the clarinet pov it wouldn't change much to define at the contract level. And clarinet relies directly on the clarity-vm, so right now there is no mechanism to add a custom version of clarity |
Beta Was this translation helpful? Give feedback.
-
|
Any way we could remove any non-standard LISP syntax, for example: @MarvinJanssen and I were discussing the idea to write LISP code to generate Clarity code as a DSL and having LISP strict syntax would be helpful. One application would be to have full LISP turing-complete environment for test cases. Other cases would be to leverage LISP macros and other matured tooling. |
Beta Was this translation helpful? Give feedback.
-
|
The testing framework with node has been released Deno testing has been removed in clarinet 2.0 |
Beta Was this translation helpful? Give feedback.
-
We want to re-evaluate some design choices that we made when we started Clarinet.
Our initial rationale was to create a tool that would assist you writing clarity code, and some unit tests without having to deal with the usual dependency hell coming with node.
Embedding Deno in Clarinet is coming with a cost:
Switching to Node would let us address all the points above, but would come with a cost: developers would have to install node on their machine, if they want to run clarinet tests.
11 votes ·
Beta Was this translation helpful? Give feedback.
All reactions