-
Notifications
You must be signed in to change notification settings - Fork 677
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
Add unit tests in Clarity #4100
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## next #4100 +/- ##
==========================================
- Coverage 85.08% 82.06% -3.03%
==========================================
Files 429 429
Lines 302009 302009
==========================================
- Hits 256976 247832 -9144
- Misses 45033 54177 +9144 ☔ View full report in Codecov by Sentry. |
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.
LGTM
(define-constant ERR_NAMESPACE_NOT_FOUND 1005) | ||
|
||
;; @name: test delegation to wallet_2, stacking and revoking | ||
(define-public (test-name-registration) |
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.
In a future PR I think it's doable (and a bit challenging too) to enable tests with parameters, to run those tests also as fuzz tests:
(define-public (test-name-registration (hashed-salted-fqn (buff 20))
(stx-to-burn uint)
(namespace (buff 20))
(name (buff 48))
(salt (buff 20))
(zonefile-hash (buff 20)))
The tricky part might be the extra work around regexes, though the heavily lifting part around fast-check shouldn't be an issue.
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 think we can specify parameter testing / fuzzing with annotations. The regexes originally came from a concept implementation to enable us to write Clarity tests in Clarity. After that, they were good enough so we just left it. If we want to make it more robust we will need to switch to a LISP interpreter, should not be too hard.
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.
If we can sort this part out, I can integrate this with fast-check and we'll have it generate/fuzz everything for us. What's very nice about this is the shrinking part; if there's a bug/edge-case detected, fast-check will give us the minimum counterexample and a seed to reproduce the failure (if the bug/edge-case is detected when running on CI).
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.
Naturally I much prefer writing tests in Clarity. The question is do the other code owners like (or at least are they OK with) bringing this new testing paradigm into the repository. Who decides?
(define-constant ERR_NAMESPACE_NOT_FOUND 1005) | ||
|
||
;; @name: test delegation to wallet_2, stacking and revoking | ||
(define-public (test-name-registration) |
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 think we can specify parameter testing / fuzzing with annotations. The regexes originally came from a concept implementation to enable us to write Clarity tests in Clarity. After that, they were good enough so we just left it. If we want to make it more robust we will need to switch to a LISP interpreter, should not be too hard.
@@ -0,0 +1,138 @@ | |||
import { ParsedTransactionResult, tx } from "@hirosystems/clarinet-sdk"; |
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.
Hey, do you think you can add some method-level comments for each of these functions in this file and the clar.test.ts
file? I'm having a hard time following how these functions fit together. Thanks!
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 parser evolved over time during our work on sBTC Mini. We just discussed in the Clarity WG to clean it up and perhaps introduce a more robust parser. The current files have served our needs and were recently edited to support clarinet-sdk
.
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.
Comments have been added
|
||
export function getContractName(contractId: string) { | ||
return contractId.split(".")[1]; | ||
} |
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 parser looks somewhat involved. Is there a way to add a (simple) set of unit tests to verify that all the test parsers work as intended? Thanks!
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.
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.
Code improvements have been pushed
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.
…sed tests - Implemented property-based testing for string, uint, and tuple conversions using fast-check. - Defined custom arbitraries for generating 128-bit unsigned (uint128) and signed (int128) integers. - Enhanced test robustness and coverage by automatically testing a wide range of input values. - Included fast-check's shrinking feature to identify minimal failure cases, aiding in effective debugging.
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.
Pulled & followed the logic due to familiarity w/ mini. My only feedback here is to make an issue for documenting how these tests are built & how a contributor can write additional tests.
LGTM.
@MarvinJanssen @friedger I like the approach here, and what you're trying to do. my concern is that if we need to make changes, the bar to getting them merged to merging to next, and updating next is less of an issue i'll agree. i'm thinking longer-term though, when eventually next is merged to master and we may find issues/improvement that should be made. having this in a separate repo would make those changes much easier to make. |
@wileyj I agree. As there is currently no other repo, this seems to be the only solution to get a good discussion. Merging a version update of the tool into main should be as hard as updating the source code 😉 |
that's what concerns me actually - unless i'm misunderstanding the reasoning behind this PR, i see a lot of benefit in moving most (or all) of the tooling outside of the blockchain repo (we can still maintain a higher bar for merging PR's, but maybe not quite as high as the blockchain repo requires). |
Being discussed tomorrow. |
using clarunit now: #4203 (comment) |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Description
This PR adds the ability to write clarinet-sdk tests in Clarity.
As an example a simple unit tests and a simple flow tests was added. These tests do not test anything meaningful, but show how these tests work.
Applicable issues
Additional info (benefits, drawbacks, caveats)
Checklist
docs/rpc/openapi.yaml
andrpc-endpoints.md
for v2 endpoints,event-dispatcher.md
for new events)clarity-benchmarking
repobitcoin-tests.yml