I will do the cypress stuff

I was just hoping to get a bare bones classic quasar repo to play with and do the install myself

Sorry for the confusion

How do I spy on Vue component methods? I tried spying on it like in an emitted event example I saw, but that isn't working, probably because it isn't an event. I don't want to test that the mutation actually happens, just that 'deleteEvent' or 'removeEvent' was called. I've searched for how to do this with no luck, but I feel like it should be very possible to do...

Since your

removeEvent

is marked as private, it is considered an internal. In other words, it should stay an implementation detail. When you will want to refactor this component to make it more simple or to use more modern technology, this test will have to be changed. I do not think you want that. Is there a behavior that this method triggers on your component? Emitting an event, changing the UI, displaying a popup, changing the url? What is it you are testing?

You could extract an instance of your component using ref and spy on the methods on the ref. https://vuejs.org/v2/guide/components-edge-cases.html#Accessing-Child-Component-Instances-amp-Child-Elements But I think this might look clunky and odd

Remember that your tests are your best documentation

So they should as much as possible be clear to read

The removeEvent mutation is what it triggers, which is shown on the far right of the screenshot. I don't know if I need to reference 'deleteEvent' or 'removeEvent', it is part of my question. If this helps, this is the component I'm trying to test. It is like a context menu that exists for every event in the system. I just want to click the 'Delete' button(link) and make sure it triggers what it should. Isn't the very next thing it triggers the 'deleteEvent' method? So I want to know how/what to spy on that to make sure it is called. Wouldn't that effectively decouple it from the rest of the details?

Oops, forgot to share this as well

Here is the rest of the component under test and the actual test as well. I mount and pass a static event directly to the component as a prop. The component just has menu items that can be clicked

So you want to test that a Vuex mutation is actually being called when you clikc right ?

Why not spy on the mock store ?

I think I could, but then I think I would have to commit the event to the store first, because that isn't happening right now. I thought the better approach was just testing what the click triggers, but I guess what you are implying is that doing this isn't really testing anything useful? It is a really low level component. But I'll do it w/e way is simplest to implement too...

The main idea of component testing (and unit testing) is to check that a black box behaves the way you expect.

This way, changes in the code, for optimization, clarity, or adding new functionality should not change the results of the tests.

One set of input should get you one set of outputs

As a rule of thumb, though, if you want to avoid testing that the framework you are using actually works make sure to ask yourself this question every time: Will this test honestly make me gain time in the future or not?

sure, that makes sense. Maybe what seems to be muddying the waters here is that the button to delete an event lives in this component, but events being added to the store happens 2 component levels up (BaseEvents I believe). So where does it make the most sense to test delete functionality? Where the app itself actually adds something that can be deleted, or the component where the link actually lives? If it is the first, then I wonder why not just make an E2E test out of it anyway? Speed maybe, but organization is another thing I think about. It seems that some of the 5 menu links seem fine to test inside of the EventMenu component, but if not all of them, it feels weird to kind of spread them out, without a good way to make it clear why that was done. I've been wondering a lot lately about what level to put what tests and how to organize component tests, and the effect on the the amount of mocking required that I think decisions like this would have. Kind of a lot of concerns here, I hope it makes enough sense...Would you maybe conclude that the EventMenu component doesn't actually require any component tests?

Unit tests are supposed to consider a component in isolation. I like to consider only inputs and outputs. The way I would test any component would use the following Inputs: - The props - The interractions: click, touch, hover, mousevent, scroll Outputs: - What the component looks like (visual regression) - The text that can be read (using testing library) - Events emitted (using spies on Cypress.vue.eventcalled) - Vuex action/mutations that are called (using spies on those functions)

If you like to consider units at a higher level it is absolutely fine, you will have more inputs to click on and more to check at once. But the tests will be seriously more valuable too.

Does it make sense?

Mostly, but again, I thought earlier you were implying that spying on 'deleteEvent' wouldn't be a very useful test because all we are doing is making sure an implementation detail calls another implementation detail. Or something like that? But now I'm not sure if you are saying that is normal. Because 'Delete' is definitely something you can click on (input) within this component, and it triggers a mutation (output). And for the 'EventMenu' component level, I'm still not sure if you think spying on what triggers the mutation is better than actually making sure the store gets updated appropriately... But maybe if you could show me an article the describes exactly how to spy on component methods/Vuex mutations, that would be better. Regardless of whether it is right at this level, it is something I want to understand better and google hasn't given me very direct info so far. And this code exactly like this does not work: it.only("Delete", () => { const deleteSpy = cy.spy(); Cypress.vue.$on('removeEvent', deleteSpy); cy.findByRole('menuitem', { name: 'Delete' }) .click() .then(() => { expect(deleteSpy).to.be.calledOnce; }) });

I tried "on('deleteEvent'" too

and on click I think, haha, I don't know what I'm doing obviously

I was unclear and I apologize. What I wanted to say was: "If nothing comes out of your component, you should not test the changes/function calls that happened inside"

I mistook the mutation you were metionning for an internal method

ah, ok, no problem.

Now to test Vuex stores, you might have to change your tests a bit

If it helps, this was the code from the vue component test readme that I was trying to copy, I didn't think it would work, but I haven't found anything better to try yet.