Need JSDOM based Unit Test

[TsayAdobe]

Milo websites tend to use multiple domain names such as hlx.page, hlx.live, adobe.com, and stage.adobe.com in their code conditional branches. However, it is easy to make mistakes while handling these domain names, so it is important to have unit tests to ensure the quality of our code.

Currently, our web test runner runs unit tests in a browser, which limits our ability to mock certain objects such as window.location. To overcome this limitation, we can use JSDOM and NodeJS-based unit tests to provide more flexibility in these situations.

I suggest that we use a naming convention for our tests to distinguish between web-test-runner tests and JSDOM tests. For example, we can use *.test.js for web test runner tests and *.jsdomtest.js for JSDOM tests. This will help us to easily identify and run the appropriate tests for each scenario.

[JasonHowellSlavin]

I like it. I think there has also been some issue with race conditions in unit tests due to running the tests in browser. I know modal.test.js faced some of these issues. Do you foresee using JSDOM to solve for some of those types of isses?

Would there be a distinct set of guidelines as to when to use jsdom tests vs. web test runner. I think it would be a good idea for at least a loose set of criteria so we aren't writing tests two ways without some sort of clear delineation in reasoning.

[auniverseaway]

I do not see JSDOM solving more problems than it causes.

The race conditions we have in the browser at the moment are (from what I've seen) are due to poor test isolation. The browser executes so fast (especially locally) that we have to add pauses because we're re-using DOM elements or "expecting" things too quickly.

Moving to JSDOM would mean having to mock a lot of the browser... we don't have to do that today.

Things like intersection observer, match media, or fetch all have to be re-built in JSDOM and using the browser gives us all of that for free... not to mention, the browser is more representative of the the ENV we are working in... why would we want to fake that in JSDOM?

I don't know why we would give up the browser just because we have to work around window.location. Is using the browser perfect? No. Is it better than JSDOM? In my opinion, yes. The same goes for the entire Franklin community which is using WTR.

Would there be a distinct set of guidelines as to when to use jsdom tests vs. web test runner.

@JasonHowellSlavin @TsayAdobe to be crystal clear: we (I) do not want two unit test frameworks. We are trying to reduce how much or engineers have to learn, not make it bigger. Having two ways to do the same thing adds a level of training and complexity we try to avoid at all costs.

[JasonHowellSlavin]

That makes sense. @TsayAdobe maybe we could look at the code which led you to want to use JSDOM?

@auniverseaway is there a way we could prioritize looking at the current tests to ensure proper isolation like you are mentioning? I remember seeing in a #milo-dev that there were folks experiencing intermitted test failures.

It also occurs to me that if we are using the browser, we should maybe think about tests the same way Testing Library does (using a11y querySelectors, etc.). and write tests that reflect what would occur for a user on the browser end, where applicable.

[hparra]

We should first fix the build before we consider this. See https://github.com/orgs/adobecom/discussions/626