Recommended ways to go about interaction testing

[Katli95]

So I'm running unit tests for slate-react on the jsdom with @testing-library/react.

1. Does anyone have any experience with a similar setup?
2. When testing interactions, do you think I should simulate mouse & keyboard or use slate.Transforms?
   • I'm relying a bunch on Normalizations & onEvent() handlers

I've seen the lib itself tends to rely on Transforms and I'm mainly wondering if that's recommended/stable in most cases?
And additionally, if maybe there was a better way than reacting to native onKeyDown events for doing stuff of that nature.

[Katli95]

Well 2 days later it's become apparent that there's no real way to do it (without browser emulation at least) 😅

The comments in #4903 outline arguments for not really unit/emulation/jsdom testing slate as it's functionality is so closely coupled to that of the browser (and the differences between browsers) and therefore recommend preferring e2e testing libraries. Another reason not to use jsdom is that there's no real support for contenteditable or beforeinput events.

The comments in #4928 then mention the decision to use full playwright e2e tests, at least internally.

@ianstormtaylor, @dylans,
Would you say this summary is accurate for the current position of the library?
I'm wondering if the docs should maybe be updated to reflect the most current recommendations?
I'd be open to contributing, but right now aiming to go down the cypress component testing route personally.

[Katli95]

Thanks for the reply. Do you mean you only snapshot/equivalent test that the thing renders what you expect? I.e. I don't see how you use slate-hyperscript to test any interaction?

I'm primarily interested in testing the result of user interaction as I'm making a fairly complicated builder that adheres to a strict schema and the interplay of events and esp. normalizations becomes hard to reason about.

I'm already having good success with cypress component testing. Albeit all the typing has to happen in one go of .type() as otherwise the editor loses focus and the caret gets lost if I try chaining them 😅

[gerardnico]

Slate Hyperscript allows you to create the slate tree state easily.

You apply then the function that get called when the user interact (button click, ...)

You get a new tree and you check that it's what you want as resulting tree.

Slate tests are build this way.

[Katli95]

Yeah that's what I thought you meant, that's not really what I'm looking for 🤗 I'm trying to test the functionality of my code, as irrespective of slate as I can. I.e. I'm asserting as little as possible about it's internal state or structure to focus on my own business logic and not testing slate's implementation of anything.

My users interact with my solution through a keyboard and mouse so I'm testing with those as the inputs and then accessing the outputs through the onChange event (parsing it to my business model) and asserting that it is the way I expect.

But thanks again for responding, and frankly making the discussion, I was half afraid I wasn't going to get any responses 😅

[gerardnico]

I got on my computer ...

You got 2 levels of test:

• functional test (hyperscript, quick, a lot)
• e2e test: Browser test (slow, less)

All examples can be seen in the repo:

• Hyperscript functional test
  https://github.com/ianstormtaylor/slate/blob/main/packages/slate/test/transforms/delete/path/block.tsx
• E2e with playright
  https://github.com/ianstormtaylor/slate/tree/main/playwright/integration/examples

[Katli95]

I got on my computer ...

🤔? You mean, because you are exasperated by me not getting your point? I meant no offense with anything I said.

• Hyperscript functional test
  https://github.com/ianstormtaylor/slate/blob/main/packages/slate/test/transforms/delete/path/block.tsx

Exactly, this is the kind of testing that only proves that slate does "what you ask it" correctly. Not what I'm looking for.

• E2e with playright
  https://github.com/ianstormtaylor/slate/tree/main/playwright/integration/examples

Thanks for pointing this one out, I'd stumbled upon it too. But as you say, e2e tests tend to be slow, that's what prompted me to start this discussion, I was looking for a faster alternative that could still test interactions. I'd expected to find a section in the docs on how to go about testing the solutions I'm making with slate, but didn't find any, it would be nice to spare newcomers the experience of having to find out by themselves that interaction testing is basically infeasible without browser emulation (kinda obvious I guess when I write it out, but I didn't know of the jsdom limitations when starting to look into this).

And as I said, I'm now happy with my current solution of using cypress's component tests as they give me (kinda) the best of both worlds. Since jsdom doesn't support half of what it needs to test slate it seems cypress component testing is the fastest way to simulate interacting with a mounted component

1. without going into hosting a full server & the whole shebang that comes with regular e2e
2. while still allowing one to assert on the outputs and internal state of the component

I'm mainly leaving this discussion open so that the maintainers can give their thoughts, if they don't, maybe I'll just close it. I just think this is a discussion that is beneficial to the slate community and would love to see some input from the maintainers, there are definitely other things in the docs that could use some attention, and I'm open to fixing some of them up.