https://cypress.io logo
Join Discord
Powered by
actually <@437702410945953802> my fixtures folder ...
# help
k
actually @wonderful-match-15836 my fixtures folder is full of Markdown files and I'm working on testing the popular 
vite-plugin-md
plugin which uses Vite to transform the MD files to components so it is in fact the directory where my "components" reside. I did move test files into the fixtures directory to see if I could get this to work but it didn't recognize it there either.
w
Let's go to thread and see what's happening: 
componentFolder
should point to where your specs are, not where your components themselves live
k
i see, I guess I can understand the logic of that but the example on the website seemed to point to 
src
for this config item
w
there's a common pattern that people colocate the specs with the components in the same folders
k
yes I've seen that but typically try not to do that
ok and so the 
componentFolder
prop sits at the root of 
cypress.json
or is nested into a 
component
prop? I've seen both
and have both atm
what I originally had configured for was to have all component tests at 
/test/integration/my-test.test.ts
i have the plugins, downloads, support directories hanging off of that
for library code the term "integration test" is as close to an "app test" as you'll get
w
looks like either top level or nested under 
component
works from what I can see. The main thing is, the 
componentFolder
will be the root that your 
testFiles
pattern applies in. 
"**/test/integration/**/*.test.{ts,jsx,tsx}"
looks like it will work fine if you just don't specify a 
componentFolder
at all
though since your e2e pattern looks really similar, you might end up matching both e2e and ct specs
k
I probably won't have any e2e tests here as there is no App per se
i might add some in the example app but that's a separate package in the monorepo
so what you're describing is almost very close if not exactly what I started with
does cypress object to commented out lines in JSON?
aka, JSONwithComment
i haven't been doing that I just wanted just now
w
what I think happened to you is, in 
open
mode, not 
open-ct
your component specs matched your top-level testFiles pattern, and since the top-level testFiles pattern and the integrationFolder you configured don't conflict (no reference to /fixtures), it was able to match... but since those are component specs, not actual e2e specs, trying to open them without starting with 
open-ct
would not work, even though the files match
k
Copy code
json
{
  "downloadsFolder": "test/integration/downloads",
  "fixturesFolder": "test/fixtures",
  "commandsFolder": "test/integration/support",
  "videosFolder": "test/integration/videos",
  // "integrationFolder": "test/integration",
  "screenshotsFolder": "test/integration/screenshots",
  "testFiles": "test/integration/**/*.test.ts",
  "pluginsFile": "test/integration/plugins/index.ts",
  // "component": {
  //   "testFiles": "test/integration/**/*.[spec|test].ts",
  //   "componentFolder": "test/integration"
  // },
  "componentFolder": "test/integration",
  "supportFile": "test/integration/support",
}
here's what I have now
w
what I think you need is:
Copy code
component: {
  testFiles: {your pattern}
}
and probably you don't need to specify 
compoentFolder
anywhere
since your pattern includes 
test/integration/
k
ok well i tried that but got this
w
got it, it's looking in the default component folder, ok so let's keep componentFolder, and remove 
test/integration/
from the 
testFiles
pattern
the pattern should only be what's needed to match specs inside the 
componentFolder
you specify
k
is it supposed to look like this?
I'd have thought it would only list the test files matched in a glob pattern
though we no longer have a glob pattern
w
what is your current 
testFiles
value?
k
oh I thought you said I should remove it ... so i did
w
no I just meant to remove 
test/integration/
from the testFiles pattern, the rest should stay
k
gotcha
believe it or not I swear this is what I started with
w
as it was it was trying to match 
test/integration/test/integration
k
ok i think it might be working at least it's closer than it has been
w
nice, yes at least you can find your spec now and open it in the correct Component Testing mode
k
Copy code
ts
describe('loading a page with tabular format correctly presents', () => {
  it('load a markdown file with a code block', () => {
    const c = mount(TsCodeBlock)
    c.pause()
  })
})
now I'd expect the component to visually load
and then pause
but it's just saying that my tests are loading
w
what's the whole file? does the return value of a mounted component have a 
pause
method? Or did you mean 
cy.pause()
?
k
oh. i may have meant cy.pause ... let me check that
well the effect is the same
Copy code
ts
import { mount } from '@cypress/vue'
import TsCodeBlock from '../../fixtures/ts-code-block.md'

describe('loading a page with tabular format correctly presents', () => {
  it('load a markdown file with a code block', () => {
    const c = mount(TsCodeBlock)
    cy.pause()
  })
})
i believe that async/await is all hidden away with Cypress, right?
i just wanted to see that MD -> VueJS Component load and display
w
yeah that makes sense, I don't know enough about your setup to debug, but what happens if you hard refresh (have needed to do this sometimes with the alpha), and are there errors in the console?
k
we use a shim:
Copy code
declare interface Window {
  // extend the window
}

// with vite-plugin-md, markdowns can be treat as Vue components
declare module '*.md' {
  import { type DefineComponent } from 'vue'
  const component: DefineComponent<{}, {}, any>
  export default component
}

declare module '*.vue' {
  import { type DefineComponent } from 'vue'
  const component: DefineComponent<{}, {}, any>
  export default component
}
that allows the import of the MD file and then I transform that to an SFC syntax
oh i've hard reset a couple times 🙂
w
and the console/terminal? Like are we fully hanging or is there an error logged somewhere
k
hmm. yes ...
doubt the sourcemap matters (it's a feature I'm working on next)
but the 404 is a bit odd
meaning ... I mounted a component, i'm not using a router
sort of feels more like an E2E error message than a component error
w
yeah not sure what is up there. I'd suggest the next step is verify that you can import and mount a plain ol vue component first, then debug from there
k
well that works just fine ... I have hundreds of other tests
i could be making a dumb mistake though due to my lack of hands on with cypress
still I had thought this was pretty much boilerplate
i have already looked at the example repo you have
but there is no boilerplate for Vite and Typescript (that I found)
viteJS is really the critical piece as this code depends on the ViteJS pipeline to transform the MD to Vue and then mount
does this indicate it can't find the test file?
that's how I'd read it ... but I can't make sense of it as I'm simply clicking on a file that the UI has found
w
what's the actual URL in the browser when you visit the spec?
k
there is NO URL
it's a component test
aka, you mount the Component
and then test it
w
right but like, you have an address bar in the browser that cypress uses to navigate to the spec
iirc
k
here's an example from your site
i'm doing almost 100% the same thing now (with VueJS)
this maps to the correct location of the file
and the URL is generated by the Cypress UI
(aka, when I click on the test that it's identified)
oh ... it cut off the beginning of my clip
w
yeah that's all I was asking for, to see if anything in that url looks like it would explain the 404, since it is the source of the filepath used to load the test
have you killed and restarted cypress since we did all the config changes? wonder if there is some how a cached list of specs that matches a previous config
k
so many times
including just now
Copy code
ts
import { mount } from '@cypress/vue'
import TsCodeBlock from '../../fixtures/ts-code-block.md'

describe('loading a page with tabular format correctly presents', () => {
  it('load a markdown file with a code block', () => {
    mount(TsCodeBlock)
    cy.get('h1').contains('foobar')
  })
})
my test is now almost a 100% replica of what you have on the site
I have about 80% test coverage in units
just want to test some of the nuanced rendering parts with Cypress
w
let's rule some stuff out, what if you comment out the imports and just do nothing in the test? does it stay in the loading state, or does it warn that you haven't used mount? Still trying to figure out if the problem is the vite setup
k
Copy code
ts
// import { mount } from '@cypress/vue'
// import TsCodeBlock from '../../fixtures/ts-code-block.md'

describe('loading a page with tabular format correctly presents', () => {
  it('load a markdown file with a code block', () => {
    // mount(TsCodeBlock)
    // cy.get('h1').contains('foobar')
  })
})
same error
Copy code
ts
/// <reference types="vitest" />
import { defineConfig } from 'vite'
import Pages from 'vite-plugin-pages'
import Layouts from 'vite-plugin-vue-layouts'
import Vue from '@vitejs/plugin-vue'
import CT from 'cypress-types'
import Markdown, { code, link, meta } from './src/index'

// used for testing, library code uses TSUP to build exports
export default defineConfig(() => ({
  test: {
    dir: 'test',
  },
  plugins: [
    Pages({
      extensions: ['vue', 'md'],
    }),
    Layouts(),
    Markdown({ builders: [link(), meta(), code({ theme: 'base' })] }),
    Vue({
      include: [/\.vue$/, /\.md$/],
      reactivityTransform: true,
    }),
    // CT(Cypress),
  ],
}))
w
really not sure what the next step is at this point, you say you have other cypress component tests that do work?
k
nothing in this repo
this is my only test
Note: that in all my current use cases I need to have Cypress and Vitest play nicely together
it would be really awesome if there was an example project that had TS/Vite/VueJS/Vitest
this is an increasingly common stack in modern VueJS
Vitest is nice that it doesn't pollute the global namespace but some of Cypresses symbols can cause conflicts if you're careful
w
sure, that would be a good example repo to have.
I don't think I can be more help to you over discord, it seems like the next step would be to open an issue with details on how to reproduce this problem, then somebody can take a better look
k
well it's an open source project so I guess I can put this attempt into a branch and isolate it
w
that'd be ideal
k
but I need to get a really big PR out and I guess for now I'll have to do it without Cypress 😦
i might try just loading the DOM stuff with Vitest and Happy DOM but that's really quite second best
the test with Happy DOM might be illuminating though
if there's any useful learnings I can pass it along
btw I created a Vite plugin which uses AST to automatically generate new user types for Commands on HMR and then give the user strong typing immediately
i had it working before in an older repo and I've updated it today but without it work now I can't really say it works yet ... though all the units pass and it will work
if someone on your team were interested in that I'd be happy to pass it over as it really improves the DX when you're working in TS
w
sure feel free to share that. and when you create and issue feel free to tag me on gh and I will check out the reproduction - @marktnoonan
k
I'm working with Anthony Foo on this repo; I think with this PR I'll actually be the biggest contributor ... but it's only got 325 stars atm but I think that could grow considerably as the core features are going to reach a lot more base uses cases very soon
I'd like it to be a showcase of good testing with both Vitest and Cypress
hope you can help me get there
I feel completely stumped atm
Well Mark ... just as I was imagining opening a bottle of wine ... I tried one more thing
There's a feature flag that was being used in VueJS for the 
<script setup>
components which I had been turned on. I turned it off and now it loads.
i need to look at whether Anthony felt that was important but I doubt it is
... there are some weird peculiarities ... with the feature flags all turned off I can render in one format but not another but using a browser both formats work without issue and unfortunately the one which uses tables for layout is the one which needs more testing right now but doesn't work
also not sure if you've seen this error before but I'm getting it from cypress when I run vitest:
seems like it might be a quick fix with switching your EJS files to use the 
.mjs
extension
yeah nothing is loading again ... didn't really change anything other than going back to the "spec" convention so I could avoid conflicts I was getting with Vitest which I'm sticking with the *.test.ts naming
400 errors are still showing on server
but error stack in browser is fully within the runner and I can't make much sense of it
I'm going to go back to my line of thinking about drinking a bottle of wine
4 Views
PreviousNext
Powered by