-
Notifications
You must be signed in to change notification settings - Fork 147
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 <dev@j-k.io> Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: j-k <dev@j-k.io> Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: j-k <dev@j-k.io> Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: j-k <dev@j-k.io> Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
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.
| 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.
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.
Setting these top-level properties as required ends up causing a bunch of ConfigLoader-related tests to fail because of the missing properties... I lean towards making them optional for flexibility since those test cases were likely based on actual use cases 🤔
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.
Hence the comment about having two top-level schemas, one for the full config with all required elements required, and one for overrides... Makes maintenance more complex however. I wonder if we could achieve it in Typescript alone with either the Required<type> or Partial<type> utiulity types? I think wrapping Required around the current generated type would make all the top-level properties required and give us the type safety where we need it without extra schema?
WDYT?
| 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.
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 looked into setting default values for these in the schema config, but unfortunately the generated types don't enforce the defaults anywhere.
Maybe we could have a constants.ts file to centralize these - or perhaps a defaults.ts file to make sure these are consistent? Right now we have default values scattered between the proxy.config.json, config/index.ts and a few other spots as a fallback for the getSomeConfigValue() functions.
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.
See previous comment about using Required. Types can't enforce the defaults, but they can enforce a value being set. If the value is required to be set (in a full configuration) then no default is needed. That could be a neat solution, i.e. functions like loadFullConfiguration returning Required<GitProxyConfig> - although they might need to confirm that all those values are set on load and throw an error if not (e.g. because someone messed with the default config).
| ], | ||
| }, | ||
| }); | ||
| 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?
Co-authored-by: Kris West <kristopher.west@natwest.com> Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
…om/jescalada/git-proxy into 1150-vitest-migration-from-service
Co-authored-by: Kris West <kristopher.west@natwest.com> Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: Kris West <kristopher.west@natwest.com> Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: Kris West <kristopher.west@natwest.com> Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
…om/jescalada/git-proxy into 1150-vitest-migration-from-service
Co-authored-by: Kris West <kristopher.west@natwest.com> Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: Kris West <kristopher.west@natwest.com> Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: Kris West <kristopher.west@natwest.com> Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
…om/jescalada/git-proxy into 1150-vitest-migration-from-service
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.