What is the recommended approach for testing the pages/routes of a vike app?

[jasonhilldm]

I am experimenting with using vitest to test the different routes of my app. If I try and debug the Page components directly, then the pageContext isn't defined and there are obviously no route parameters. Is this a viable approach where I somehow construct the pageContext in the test setup?

I also notice in the vike examples that you are using a bespoke e2e testing module which fetches urls and inspects the returned html. Is this the preferred approach for testing pages in a vike app?

Using the fetch approach though, I don't know how I can mock the data fetched in my telefunc functions. I have tried to mock those, but I am not calling the functions directly from the tests so the mocks aren't being used. Any quick pointers greatly appreciated.

[brillout]

That's indeed what I find works best, i.e. having two level of tests:

• Low-level unit tests: testing small-ish bits of logic (usually implemented by pure-ish functions).
• High-level E2E tests: fully run the app then simulate a user with a real browser.

For unit tests I recommend using Vitest as, in my experience, it works great for that purpose.

As for E2E tests I ain't aware of any satisfactory tool (that's why I wrote one for Vike). I know Vitest introduced browser testing not that long ago, but I don't know how good it is yet. Contribution welcome to explore using Vitest for E2E tests.

Keep me updated about your findings.

Would be nice to have a test guide on Vike's docs at some point.

[jasonhilldm]

I have been able to use Vitest with browser testing to fetch urls from the local server and then use cheerio to inspect parts of the returned HTML to make sure the page content is structured correctly.

But, I have still not been able to figure out how to mock the telefunc calls though as calling vi.mock() for those imports doesn't seem to work. I'm not sure if this is something specific to telefunc or if it's because the telefunc call is happening as part of the fetch() and maybe it's therefore outside of the Vitest scope. Any ideas?

[brillout]

I'm not sure if this is something specific to telefunc

Dig further and let us know if you find evidence that the issue is on Telefunc's side.

Any reason you aren't following this recommendation?

High-level E2E tests: fully run the app then simulate a user with a real browser.

[jasonhilldm]

Any reason you aren't following this recommendation? (High-level E2E tests: fully run the app then simulate a user with a real browser.)

I am using that approach - I am fetching URLs from the localhost using headless mode in vitest, but I still wanted to mock the data access. The tests are going to be running in a CI environment so there won't be any local database. I could potentially let the tests hit the live database or a copy of the live database but, typically, I would mock the data access. What do you do with data access in your E2E tests?

[brillout]

I'd use the same setup and database as local development (or stating). No need to mock Telefunc then. That's a neat thing about E2E tests as they piggy back on existing setups (local dev and/or staging environment).

Another neat thing about E2E tests is that they don't need to watch for changes as E2E tests are mostly about ensuring that the main functionalities of the app is working before releasing to production, whereas unit tests are mostly about quick development.

In general, I think 100% test coverage is counter productive, instead I'd only test complex units (using unit tests) and only tests whether the main functionalities of the app are working (using E2E tests).

So far I think this dual approach of unit tests (with Vitest) + E2E tests (with a custom test runner or maybe with Vitest in browser mode) is a solid strategy. But I'm happy to be shown wrong.