Definitely! Just fyi though I'm such a rookie in this realm haha

No problem! When we do our next round, I'll reach out to schedule. Is via Discord ok?

Sounds awesome 😄

@User The initial numbers are in from the rewrite/rearchitecture of Cypress Component testing. I retested https://jess.sh/crossword in both versions. Test Setup: * 8 specs + 21 tests (including an App.spec.js w/ router + store) * No stubbing/mocking of any components. * The heaviest component tests had 882 total events (click + input) and 452 components rendered at a time Timings: Entire Suite * Old version: 47.57 seconds (incl bundling + specs) * New version: 4.5 seconds (incremental build), + 2s startup for dev server = 6.5 seconds total Timings: HMR when in workbench mode (vs. "TDD Mode") * Old version: No HMR support (needed full rebuild... usually ~5 seconds) * New version: Full HMR support (as fast as your dev server.. milliseconds) * Timings: HMR when in TDD Mode* * Old version: No HMR support (needed full rebuild... usually ~5 seconds) * New version: HMR support, but needs to blow away the iframe for fresh start... (as fast as a cached page reload) (Workbench mode is when you're not running your specs on every change... vs TDD mode is when you're running your specs on every change)

The end result is that incremental builds seem like they're gonna be faster than Jest.. Jest operates in seconds for incremental builds once watching.

My bet is that full suites in CI will be slower than Jest... but that the DX of developing components + local TDD will provide something new in contrast to TDD w/ Jest for components. We have a long way to go until we can stand by these metrics and publish them on Twitter or in a blog post... ... but I'll post videos and gifs once we clean up the UI a bit more

Holy moly the entire test suite is an order of magnitude faster almost

Like you said, the interactive runner experience overall more than makes up for it

Im so keen to move out of a terminal into a proper work bench

A demo video would be really cool, keen to help out with making something

anyone know how to get code coverage to include logic in Vue

<template>

tags? After some googling, it seems like it might be a Vue limitation at the moment. When I analyze my coverage report I'm not getting any coverage on logic that's coming from

v-if

directives for example, and my coverage is saying I have 100% coverage when really there's a fair amount of logic that's not being tested. Would love if anyone has any insight into this!

Hey @User for Vue 2 or Vue 3?

Vue 2

Here's a blog post from one of our engineers https://vuejsdevelopers.com/2020/07/20/code-coverage-vue-cypress/

with an example app

I used that as a guide for setting it up, but I'm not sure the istanbul plugin is picking up logic from within the . I'm getting instrumentation on my Vue files but only within logic that's within the script tags

you need to set a script

do you have both a script and a template?

I haven't tested the template conditional logic, honestly. I don't really use code coverage too heavily. If it's not picking it up, you might wanna write your code in a way that concentrates the logic in the script side.

Perhaps @User has some experience with this?

that's kinda been my take away from researching it and pulling as much logic out of template tags as possible in SFC. Just wanted to see if anyone knew something that I didn't or if there was some workaround. My boss wants my code coverage reports for the repo but we'll probably end up using it as a very loose guideline. I saw @User replying to a similar question somewhere as it related to vue-test utils I think - figured maybe there was some way to get around it in Cypress. Thanks for the input!

IIRC Istanbul has some limitations with Vue SFC. For example, I think without

<script>

they won't be picked up at all.

Gotcha - thanks for the response!

hmm I have not played with cypress coverage for vue component tests too much (assuming that is what you are referring too). there is not reason why we can't have coverage in

<template>

in both jest and/or cypress. that said I am not sure how much sense this really makes? the way code coverage usually works is tracking which line(s) are/are not executed - in the case of a

<template>

, as long as the component is rendered, the entire thing is "executed". what kind of reporting/metrics do you have in mind for coverage in

<template>

@User? the only thing I can think of is some way to indicate the content of a conditional

<div v-if>

is never rendered or something, but I am not sure how useful that would be 🤔

Say I had a SFC that uses

v-if

to render one of two buttons. I write my tests to cover everything in my component but I forget to write one that makes sure the correct button is rendered. Shouldn't that be reflected in my code coverage?

Yeah, that's the only case I can really think of - conditional rendering. This would be interesting to explore. It might be a little tricky, but should be possible, I think... we need some way to track how the compiled

<template>

code is executed, I have no idea how difficult this would be.

It sounds like it (might) be a lot of work for (relatively) little value, but I would like to explore this more.

hm, I wonder if you write using render functions instead of

<template>

does this "just work" out of the box 🤔 it should (although not really relevant to your problem, i'd be interested to know if it does, good place to start to investigate implementing this)

Ok then I'm not crazy 😄 I feel like I have enough to go on for my work scenario. But very interesting topic. I agree that it might be a lot for little value. Super curious now to see if it works with render functions

Technically no, because that

v-if

should be a computed value or a method, ideally, which you can test. But I agree that it might be good to maybe get a warning if an inline check is done and if that's a branch that hasn't been covered