Open a-laughlin opened 3 years ago
Just curious, does this have any impact on being able to use @web/test-runner-commands
?
https://github.com/material-svelte/vite-web-test-runner-plugin/issues/11
I tried this PR out in my project, and I hit a problem. I load in some globals before my tests run by using testRunnerHtml
, like this:
testRunnerHtml: (testFramework) => `<html>
<body>
<script type="module">
window.global = window;
</script>
<script type="module" src="/test-setup/globals.ts"></script>
<script id='uit' type="module" src="${testFramework}"></script>
</body>
</html>`,
My globals.ts
does a bunch of work to set up the environment for my tests. But with this PR, it's not loading. I used wtr browser debugging, and I see this in the console:
Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "video/mp2t". Strict MIME type checking is enforced for module scripts per HTML spec.
I guess it's because it is not being handled by the transformImport
step. Does that only process files inside the testFramework
, maybe?
Just curious, does this have any impact on being able to use
@web/test-runner-commands
?11
There's a decent chance it'll help #11. Things tended to just work with Snowpack's WTR integration, and this approach is close to it.
I load in some globals before my tests run by using testRunnerHtml
I had a similar problem with my MockServiceWorker mocks file. WTR can only delegate the files that it loads to Vite. Scripts in the config html runs outside of the test framework, so WTR (thus Vite) doesn't see them with this approach. IIRC the redirect approach worked around WTR with a separate server to catch all requests. That enabled Vite to transform global scripts, but at the cost of integrations like MockServiceWorker and likely #11. Achieving global loading may be possible, but I suspect working around WTR will create more problems than it solves.
My solution was importing the dependency file from the top level of my app. That worked while simplifying the dependency structure for tools. If that approach doesn't work for you, importing or inlining plain JS should cover that case (though the more complex dependency structure will yield higher maintenance over time).
My solution was importing the dependency file from the top level of my app. That worked while simplifying the dependency structure for tools. If that approach doesn't work for you, importing or inlining plain JS should cover that case (though the more complex dependency structure will yield higher maintenance over time).
This could work for my use case. I'm trying to work with a .feature file with commands, but an import would do the trick too. Thanks for the tip!
@a-laughlin made it work with a plain text plugin. Thanks again! https://github.com/rquast/gitfeatures/commit/55d4fcd1f19268d58e2c1a6e11662b9a41c86893
I wonder if it would be possible to add an option to this plugin to specify a file that should be imported and executed prior to running the tests. I'd really prefer not to import test setup code into my actual app.
You could import it into your test files like other imports. I ended up writing a 6 line vite plugin that prepends the import into each of my test files as they load, and only in test / ci environments.
Adam
Sent via mobile.
On Thu, Oct 21, 2021, 7:46 AM Ian VanSchooten @.***> wrote:
I wonder if it would be possible to add an option to this plugin to specify a file that should be imported and executed prior to running the tests. I'd really prefer not to import test setup code into my actual app.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/material-svelte/vite-web-test-runner-plugin/pull/18#issuecomment-948633936, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI7HT7IZ2JZX2L2JPRC373UIAKSVANCNFSM5FMPW6WQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Thanks to Snowpack's WTR plugin for most of this implementation: https://github.com/snowpackjs/snowpack/blob/main/plugins/web-test-runner-plugin/plugin.js
There should be a slight speed increase due to bypassing network requests, but I haven't tested it. This implementation seems to load fewer files also.