Add unit testing #383
Add unit testing #383
Conversation
🦋 Changeset detectedLatest commit: 5b58303 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
✅ Deploy Preview for astro-starlight ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
github-actions
bot
added
🚨 action
size-limit report 📦
|
| // TODO: Stubbing BASE_URL is not currently possible. | ||
| // Astro controls BASE_URL via its `vite-plugin-env`, which prevents Vitest’s stubbing from | ||
| // working and there’s also no way to pass in Astro config in Astro’s `getViteConfig` helper. | ||
| describe.todo('with base', () => { | ||
| test('prepends base', () => { | ||
| vi.stubEnv('BASE_URL', '/base/'); | ||
| expect(fileWithBase('/img.svg')).toBe('/base/img.svg'); | ||
| vi.unstubAllEnvs(); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
Vitest provides a stubbing helper to set import.meta.env values in tests, but this does not work for values controlled by Astro’s vite-plugin-env such as BASE_URL.
It is also not possible to set Astro’s base option via a vitest.config.ts file using Astro’s getViteConfig helper — instead Astro side loads an astro.config from disk. I couldn’t find a way to get it to detect a local test-suite-specific astro.config, so for now testing for custom base settings seems to be blocked.
There was a problem hiding this comment.
This makes sense. I guess a potential approach could be a more e2e oriented test with a fixture specifying a base config option and checking after a build for example the outputted favicon path but may not be that worth it 🤔
There was a problem hiding this comment.
Yeah, that would be the hardcore way (although given withastro/astro#7561 might also be tricky to set-up without cluttering the repo with fixture directories at the base level), but seems wrong for testing a single function output 😅
| export function defineVitestConfig(config: z.input<typeof StarlightConfigSchema>) { | ||
| return getViteConfig({ | ||
| plugins: [ | ||
| vitePluginStarlightUserConfig(StarlightConfigSchema.parse(config), { | ||
| root: new URL(import.meta.url), | ||
| }), | ||
| ], | ||
| }); | ||
| } |
There was a problem hiding this comment.
This config helper wraps Astro’s getViteConfig to set virtual modules in the test environment using Starlight’s Vite plugin. If each test suite could contain an astro.config instead, we could perhaps use the Starlight integration directly instead.
| }), | ||
| }); | ||
|
|
||
| function mockDoc( |
What kind of changes does this PR include?
Description
getCollectioncalls with fake content or data entries.