-
-
Notifications
You must be signed in to change notification settings - Fork 306
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
test: migrate api unit tests to vitest #6177
Conversation
const root = new Uint8Array(32).fill(1); | ||
const randao = new Uint8Array(32).fill(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.
One observation for reviewers, it seems that chai
was matching the Buffer
and Uint8Array
equality. Which is logically wrong, if we are expecting a Buffer
instance of a value then assertion should pass otherwise fail.
For this reason have to update a lot of fixture data in this PR, converting Buffer
to actual returning Uint8Array
instances.
args: [ | ||
32000, | ||
randaoReveal, | ||
graffiti, | ||
undefined, | ||
{feeRecipient: undefined, builderSelection: undefined, strictFeeRecipientCheck: undefined}, | ||
], |
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.
sinon
assertions were passing with partial arguments as well. To pass with the vitest
we have to add the full arguments that were used to call that function.
That's because we are reusing reqSerializer for produceBlockV3
for other methods as well.
lodestar/packages/api/src/beacon/routes/validator.ts
Lines 608 to 611 in 1a63b07
produceBlock: produceBlockV3 as ReqSerializers<Api, ReqTypes>["produceBlock"], | |
produceBlockV2: produceBlockV3 as ReqSerializers<Api, ReqTypes>["produceBlockV2"], | |
produceBlockV3, | |
produceBlindedBlock: produceBlockV3 as ReqSerializers<Api, ReqTypes>["produceBlindedBlock"], |
To make it logically correct we should have different serializers for each method. Would be nice to know why it's actually written in this way in first place. @g11tech Do you remember any rationale for 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.
because produceBlockV3 serializer is superset of all of them
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.
you can create separate serializer fns for each of these but then delegate the call to produceBlockV3
inside it with so that you may not need to pass undefined values here
but we anyway will remove these fns and not support them so we can leave it like that as well
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## unstable #6177 +/- ##
=============================================
+ Coverage 80.02% 90.35% +10.33%
=============================================
Files 19 78 +59
Lines 1717 8089 +6372
Branches 155 490 +335
=============================================
+ Hits 1374 7309 +5935
- Misses 341 772 +431
- Partials 2 8 +6 |
Performance Report✔️ no performance regression detected Full benchmark results
|
await expect(fetch(url, {signal: signalHandler?.()})).to.be.rejected.then((error: FetchError) => { | ||
expect(error.type).to.be.equal(testCase.errorType); | ||
expect(error.code).to.be.equal(testCase.errorCode); | ||
await expect(fetch(url, {signal: signalHandler?.()})).rejects.toSatisfy((err) => { |
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.
can't this be changed to?
await expect(fetch(url, {signal: signalHandler?.()})).rejects.toSatisfy((err) => { | |
await expect(fetch(url, {signal: signalHandler?.()})).rejects.toSatisfy((err: FetchError) => { |
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.
Not that's the strict type issue we can't assign type inside the function descriptor.
Argument of type '(err: FetchError) => true' is not assignable to parameter of type '(value: unknown) => boolean'
🎉 This PR is included in v1.13.0 🎉 |
Motivation
Consolidate the testing frameworks and migrate to vitest.
Description
Migrate
api
unit tests to vitest.Steps to test or reproduce