[test] Setup the e2e test suite (from main repo)

[oliviertassinari]

Work on #37, test browsers

Add a test case for #96, migrate a few keyboard tests.

[oliviertassinari]

@dtassone please use absolute imports anytime possible (basically if it's not inside the source of the component). This makes it much easier to navigate the codebase, as well a refractory it.

[oliviertassinari]

@dtassone I have updated the pull request with your first feedback. Let me know what's missing so we can move forward :). The next important step for the CI will be to run the types check in on the whole codebase.

[dtassone]

@dtassone I have updated the pull request with your first feedback. Let me know what's missing so we can move forward :). The next important step for the CI will be to run the types check in on the whole codebase.

Sorry I'm not convinced about bringing all these tools.

• Why do we need karma when we have Jest?
• The repo is public, everybody will be like why we use karma over jest? New product = latest tech (top-notch)
• Why do we need all these test utils as well? Do we even use them?
• The type check is the most important step, and why we use typescript
• Why do we need babel when we can do what we want with webpack and typescript?
• What are the issues with our current stack? And what are we trying to solve?
• Is this just about realigning X with Core?

[oliviertassinari]

I don't like the term "bringing", we don't bring tools, they are already "here". The fact the code is in two different repositories only means it's harder to share. But it's the same codebase, same technical tradeoffs. We are not starting from scratch on the enterprise components, we are complementing the existing ones, reusing the infrastructure and improving it where we can. Many tradeoffs have been made in the past, we embrace the legacy, and build on top of it.

The question we should ask ourselves is: do we want to try Y for the DataGrid component? Is it more efficient? If we host the advanced Tree View or Date Range picker component in this repository, same question.

Why do we need karma when we have Jest?

Because Jest can't run in the browser, Jest can only control a browser, which is way different to run inside a browser.

everybody will be like why we use karma over jest?

It doesn't matter from an order point of view. We won't sell more or less. People care about the end result. People would keep using the MIT components even if we had no tests (take Chakra as an example) as long as we don't ship regressions every week.

Why do we need all these test utils as well? Do we even use them?

Are you referring from the code that I had to copy & paste from the main repository until we abstract it in an npm package or a shared yarn workspace? I can delete the tests, I don't think that it matters.

The type check is the most important step, and why we use typescript

I believe the public API of them has already good type-checking support, but maybe it could be improved. About it's written in JavaScript, I don't think that it matters, the objective is to abstract them away anyway to avoid duplication (it will lead to issues down the road if we don't). I think that the mental model for the new files should be: copy & paste is that cheap solution to save time and bridge the fact that we have used two repositories, that sharing the code is more challenging, but we will get there over time. The source of trust is from main, we can have periodical sync to benefits from improvements & fixes.

Why do we need babel when we can do what we want with webpack and typescript?

Babel allows us to perform code optimizations, to make it run faster. webpack nor TypeScript provide such features (as far as I know). What do you have against Babel? But better discuss it in #50.

What are the issues with our current stack? And what are we trying to solve?

I'm implementing on the conclusion of #36 (comment). Using the following ordered priorities in the tests:

1. The test can be written with testing-library
2. The test can be written with higher-level tools: Puppeteer, Cypress, Playwrite. (This is new, something you have introduced)
3. The test can be written with a visual screenshot

Is this just about realigning X with Core?

It's also about optimizing for the whole project, not one part of it. I think that we should use the following approach, the one that will allow the whole project to tackle more ambitious problems, to have a larger impact:

• We should force the confrontation of conflicting points of view. It's the best way to find the best approach. Two repositories, two different leads of part of the codebase, etc shouldn't prevent us to find common grounds.
• We should force to hit reality. Decisions and tradeoffs should be taken for with the most challenging environment in mind, not the ones with the least constraints.
• We shouldn't allow strong divergence to exist in the long term. Improvements should benefit all areas of the codebase. It's more effort to make happen but yield more value.
• Divergence should be possible.
• Divergence should start from the realization that the existing approach X isn't optimal, that Y performs better. We can't make such a conclusion without experiencing X in the current context. Once we identify a better patterns, we scale it and work on adoption in the codebase.
• We should be able to move code from the two repositories without requiring any refactoring. It should just work, the same tools should be in place.

[oliviertassinari]

I hope that we will be able to import the test folder from the material-ui repository rather than having to copy & paste the source. For now, it should to the trick. At least, it get a few tests running the CI, which a great step forward compared to having none.

Unlocks #116.