I finally gave up unit testing my Quasar app, too complicated to set up :)
I chose rather to e2e-test it. Pros and cons for each test type, but I’m using TestCafe, and it took me a few minutes to install, and a few more to run my first test.
There is even a plugin called testcafe-vue-selectors which allows asserting props, data and computed properties. Furthermore, mocking HTTP calls is on TestCafe roadmap (nock is a workaround in the meantime). Both of these points allow some of what unit tests have to offer.
My point is : I’m not convinced it’s worth putting so much effort in unit testing Quasar apps, overall, considering how easy and what can be achieved with e2e testing, TestCafe in particular.
First: hard to help you without seeing your code
Second: q-layouts do not close or open. Not sure what you are talking about.
Third: Using a v-show on a q-layout would result in the behavior you describe, as this hides the element but it still is there. Use v-if instead
Fourth: You are not supposed to have multiple q-layouts in the same file or active at the same time.
Fiftht: Have you considered using routes for this? This is how I handle it:
In this example, note the default and 404 routes. When matching a route, the first match is used. So we first look for a suitable route using layout1, then using layout2.
'/route1' would use the first layout, '/route2' the second one. You could also have a function that returns a different layout depending on a variable.
One way to do this would be a function (star in this exanple) that handles this. Using this would work if the label is text, a model, or whatever. You could put it into utils.js or something and then pull it in where needed, but here I just showing it as a simple component method. Note that the float-label attribute is now bound with the leading : so that it becomes dynamic: