Closed iliubinskii closed 1 year ago
This seems like a good idea, let's see if we can find some time to work on it Sorry for the delay, we've been focusing on Cypress AE for a while
Same issue here, I'm registering some helper functions in app.config.globalProperties
in a boot file, but when running component testing with cypress (using @quasar/quasar-app-extension-testing-e2e-cypress
), these functions aren't available.
Any workaround to manually do the boot ?
Nope, manually registering the boot file or setup what you need is the preferred way to do so Consider that component/unit testing is meant to require you to setup only what you actually need to run the test itself
Thanks, but how am I supposed to manually register the boot file?
The boot function takes the app
as a parameter, and I'm not sure how I can access it to use it in the boot function before mounting my component 🤔
Oh I found a way:
Here is my boot file:
import { boot } from 'quasar/wrappers';
export const globalProperties = {
$someHelper: () => console.log('hello'),
};
export default boot(({ app }) => {
Object.assign(app.config.globalProperties, globalProperties);
});
And then in my cypress component support file:
import { VueTestUtils } from 'cypress/vue';
import { globalProperties } from 'boot/myBootFile';
const { config } = VueTestUtils;
config.global.mocks = {
...globalProperties,
};
Still, I think having a simple way to apply every or some boot files when component testing with cypress would be much valuable! I get the principle of keeping only the minimum for component testing, but we're only putting some very basic stuff in boot files.
As a project grows, the boot files start to get interconnected with each other (e.g. because you use a feature with a boot file into another boot file), or you may only need a bit of the code defined in the boot file, but the other part of the boot file code forces you into a cascade "I need to setup everything or mock everything"
I'm not totally against adding a boot file loader helper, but making tests much more complicated and slow to avoid a bit of redundancy isn't a good tradeoff. I'm not sure I want to encurage that pattern and we already tried creating a boot loader helper in a previous version of this package, which we had to remove due to the previously mentioned reasons
If you notice you're mocking too much stuff, you probably want to switch to an e2e test instead, or refactor your component to be easily testable
Well, I definitely get your point and it's a matter of tradeoff.
My two cents is that if no helper is made available, it would deserve to be documented to help people setting up component testing into an existing project so they understand why their test might be failing and the different workarounds (avoid boot files, mock globally in the support file with its pros/cons, mock specifically in some tests files)
We kind of already mention that for VueRouter, Pinia and Vuex here
Would you mind PRing a section to the docs right after that one, specifying that the same goes for boot files and what you expected to find in the docs on that regard?
I can then integrate the explanation with my own knowledge on why we decided not to add a boot file helper (yet)
Sorry for the delay, here is the PR for the doc section: https://github.com/quasarframework/quasar-testing/pull/346
We merged the PR and released the updated docs, gonna close this for now If anyone wants to add more complex examples to the docs, please open a PR and I'll review it ASAP
Quasar supports boot functions where I can register custom components globally:
When I use installQuasarPlugin, I don't have access to app variable to register global components.
It would be helpful to have either:
"useBoot" option for installQuasarPlugin that would call quasar's boot files
OR
boot({ app }) option for installQuasarPlugin that would accept callback that would have access to "app" variable.