-
Notifications
You must be signed in to change notification settings - Fork 146
refactor: migrate tests to Vitest + TS #1202
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
base: main
Are you sure you want to change the base?
refactor: migrate tests to Vitest + TS #1202
Conversation
…e-ts-refactor-redone
Co-authored-by: j-k <[email protected]> Signed-off-by: Juan Escalada <[email protected]>
Co-authored-by: j-k <[email protected]> Signed-off-by: Juan Escalada <[email protected]>
Co-authored-by: j-k <[email protected]> Signed-off-by: Juan Escalada <[email protected]>
Co-authored-by: j-k <[email protected]> Signed-off-by: Juan Escalada <[email protected]>
This will be removed in a later PR once the new CLI tests are converted to Vitest
|
I think we discussed "BlueOak-1.0.0" before and can add it to the licenses list |
kriswest
left a comment
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.
A huge contribution (reading it took half a day!).
A few questions about type overrides as and whether some can be removed for type safety in the tests. The schema docs generator also needs to be run (type generator was run). There's also a few places you could use vitest's assert to simplify checks.
I spotted a number of things that aren't really within the scope of this PR and commented on them. If on reviewing them you agree, either you or I should create issues to resolve those.
| "password": { | ||
| "type": "string", | ||
| "description": "Password for the given `username`." | ||
| }, |
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.
Are you able to run the schema docs generator (gen-schema-doc) to add these properties to the config reference? Give me a shout if not (i.e. if you haven't got the python env setup needed to do so).
You have run the quicktype generator (generate-config-types).
| const config = loadFullConfiguration(); | ||
|
|
||
| if (!config.cookieSecret) { | ||
| throw new Error('cookieSecret is not set!'); |
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.
We should possibly make cookieSecret required in the config schema. Currently none of the top-level properties are required... but then that lets you validate a file full of overrides (as long as the defaults cover everything that is actually required). However, its leading to our generated type for the config having these properties as optional.
This may be worth some further thought - we could have two top-level schemas (for the defaults and for override files) that reference the same defs for top-level properties I suppose. That would give us two different typescript types to use, as appropriate.
| export const getSessionMaxAgeHours = (): number => { | ||
| const config = loadFullConfiguration(); | ||
| return config.sessionMaxAgeHours; | ||
| return config.sessionMaxAgeHours || 24; |
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.
As above - no default needed if it has to be in the defaults and we have a type expressing that.
| console.log('No commit message included...'); | ||
| return false; | ||
| } | ||
| console.log(`isMessageAllowed(${commitMessage})`); |
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 is (existing) debug output, we should drop it or start doing a better job with logging!
Not a blocker for this PR, but a note to self/reminder
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 are several other places that info on why the message has failed the check is just being logged. We should refactor this to return an error message or null and then carry that forward into step.log messages, as that'll make illegal messages way less annoying to debug and we can drop all the debug logging here.
| ], | ||
| }, | ||
| }); | ||
| expect(res.status).toBe(401); |
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 should probably be a 403 - not an issue for this PR
| ], | ||
| }, | ||
| }); | ||
| expect(res.status).toBe(401); |
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 should probably be a 403
| { | ||
| label: 'I am happy for this to be pushed to the upstream repository', | ||
| tooltip: { | ||
| text: 'Are you happy for this contribution to be pushed upstream?', | ||
| links: [], | ||
| }, | ||
| checked: true, | ||
| }, | ||
| ], | ||
| }, | ||
| }); | ||
| expect(res.status).toBe(401); |
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 should probably be a 403
| ], | ||
| }, | ||
| }); | ||
| expect(res.status).toBe(401); |
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 should probably be a 403, etc. will stop marking them here
| @@ -0,0 +1,35 @@ | |||
| import { defineConfig } from 'vitest/config'; | |||
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.
Should there be a vitest config file for the cli tests as well?
Fixes #1150, built on top of #1166.
Not all tests were perfectly refactored from Chai/Mocha -> Vitest. Some required partial or total rewriting to get them to play nice.
Some tests, specifically the proxy-related tests (
proxy.test.ts,testProxy.test.tsand most importantlytestProxyRoute.test.ts) have been very problematic for some reason - the tests intestPush.test.tsseem to fail in the CI when some of the proxy tests execute prior. They fail on the first execution locally, and then pass without issue (maybe a caching/cleanup problem).Coverage has dropped somewhat to 80.5%, but we should see an increase after removing unused/untested code such as plugin stuff.
Note that the CI is failing due to the new Blue Oak license.