Philipp Fritsche
Philipp Fritsche
After thinking about this both these styles seem good to me - whatever is shorter/more descriptive for the test being written: ```js test('paste text in textarea') test('xyz does foo if...
I don't think this is entirely "fixable" as it is immanent to how the real browser applies the concept of focus: * `document.activeElement` refers to the active element inside that...
The problem with utility APIs like `selectOptions` is that they define the interaction by the effect. The user can achieve that effect by different means. So there isn't a single...
/cc @nickmccurdy @timdeschryver @MatanBobi
Can you leverage Vitest to run tests in a headless browser?
I don't know if we should run (some?) tests in happy-dom too, but I think we need to run our tests in a headless browser. In the end the browser...
A little update here: I'm trying to make this work without rewriting too much of the tests. Current approach is Karma+Jasmine with Jest's `expect`, `spyOn` and `fn` so that any...
The goal is to run tests in at least one major browser (preferably Chrome) and in Jsdom. These tests should be run from and reported to the CLI so that...
Karma looks great, as it is built on a plugin system. But there are no types and the dependency injection makes it really hard to identify which interfaces are being...
We currently implement a `combinationBehavior` on `keydown` that only implements "select all" for `Ctrl+A`. This also behaves differently on Mac. See https://github.com/testing-library/user-event/issues/778#issuecomment-966393903 I think we should not hard-code but implement...