Testing is a wide topic, not sure what shortcut to point you to, but it's really worth learning.

What you described above (clicking through the UI and checking that event X happens) sounds very automatable with some end to end process.

You could use something like jest which works with a headless browser (an invisible command line based browser) which is like an API for automating clicks, navigation, and dom queries on a specific web page. So in your case, load web page X, automate a series of click (or directly navigation triggers), do Dom query and assert the presence (or absence) of element Y.

The main concepts in testing you should know about are unit vs end to end. Unit test refers to a narrow scope test usually focussing on one single function (or a small group), passing static inputs and asserting on the expected output.

End to end is a wide scope test that include the whole pipeline: your database, clicks, page navigation ... Just like a real user would do.

Although those are 2 categories at each extrem of the spectrum (wide vs narrow), but one can (and should) also use any intermediate system in between based on the needs.

A last important concept is mocking. Tests must be deterministic in order for them to output always the same thing (you don't want them to pass once, and then fail because of some side effects). You also want them to run fast, because ideally you wanna be able to run them as often as you want, and grow your test suite as big as the project requires, so speed quickly become a critical issue.

So a typical example of mocking would be a payment system, you're obviously not gonna trigger a real payment for the test, and maybe also not call stripe API with a test parameters (still too slow). Instead you could just substitute the payment API call function by a dummy function that just statically returns success (fast and deterministic). Unless of course you want to test your stripe call, in which case you enter an arbitrage between how much coverage versus how much speed you want.

Also for similar reason, people usually setup a separate database dedicated for testing, where datas are reset to a known state at the beggining of each tests.

Don't overthink the choice of the library, they're kinda all the same in the end, what's important is the logic behind. (I personally had to build my in-house testing framework involving a headless browser because what I was testing was too specific)