docs: add WebdriverIO as recommended alternative

[christian-bromann]

I suggest to add WebdriverIO as recommended alternative as it allows the same features as Jest but offers users to run their tests in an actual browser.

Using JSDOM and JavaScript click events do not seem like a viable approach for testing component these days as they don't mimic user behavior at all. For example, clicks through fireEvent of @testing-library/vue do not recognise whether another element is blocking the access to an element. I've done a whole set of experiments showing that using WebDriver as automation protocol to mimic user behavior prevents stupid errors to pass through and also offers much more capabilities, e.g. user gestures.

For pure component tests I personally would not advice to use JSDOM at all given that:

• it lacks in certain features (e.g. triggering pseudo states) and has some known caveats
• it completely ignores the interactivity state of elements, e.g. if my component hides a button or an input is disabled, many user interactions are still possible within JSDOM and non-organic interactions via JS clicks
• mounting and rendering components in an actual browser allows the use of common developer debugging tools like DevTools rather than using e.g. screen.debug() to print the DOM tree providing a much better DX
• speed advancements are just minimal, starting a headless browser is almost as fast

Full disclosure: I am maintaining WebdriverIO. Things mentioned above have always been bothering me, which is why I introduced component testing into the framework. Yes I know there is Cypress, Puppeteer and Playwright and they also deserve to be on this page. I advocate for this tool though as it promotes usage of web standards (WebDriver) and tools that are open governed and not owned by a company.

[github-actions[bot]]

Size Changes

📦 Next.js Bundle Analysis

This analysis was generated by the next.js bundle analysis action 🤖

This PR introduced no changes to the javascript bundle 🙌