Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

End-to-end testing

See original GitHub issue


Our current snapshot testing in packages/core only does so much. It does not:

  • always make sure that the generated code is even valid JS
  • that the generated components are valid in regard to the rules of their frameworks
  • that the generated components have the features they are meant to have (interactivity, state management, styling, lifecycle hooks logic, etc.)

Another big issue is that we do not have a good idea of what features are supported by which generators at any given point. We currently have about 12 generators, and they don’t all support every single feature and edge case. It is unfeasible to manually gather that information and keep it up to date.

Ideal process

The ideal process I have in mind to accomplish this type of code coverage is to have an end-to-end testing pipeline like so:

  • write a Mitosis project containing many components in packages/testing
  • run it through the Mitosis CLI to generate a directory for each framework we support
  • render every generated version of every framework on some server (N servers for N frameworks)
  • For each framework, run the same integration test suite on each of its generated components in Storybook using a tool like Playwright

To solve the issue of identifying feature support, we would then add some logic that performs all of these tests against every output, but allows for certain failures. We then need to generate a matrix of feature support (e.g. each row is a feature, each column is a framework) that gets printed in a markdown file in the repo (where this currently lives)


So, if we have a clickable button, say packages/testing/src/button.lite.tsx.

1 - We would run mitosis build, and end up with:

  • packages/testing/output/vue/button.vue
  • packages/testing/output/svelte/button.svelte
  • packages/testing/output/react/button.tsx
  • packages/testing/output/solidjs/button.tsx
  • etc.

2- We would load all of those using parallel servers (each in its own Github Action)

3- We would then have a test, say packages/testing/playwright/tests/button.ts. This test would execute on each github action against a different server.

4- We would finally compile all of the results and generate a matrix based on what passed and what failed.

Initial implementation

The quickest way to get an MVP of this idea is:

  • Create a single, simple test (a div with text)
  • Output it to just 1 framework (React to start would be good)
  • import the generated components to a simple server that supports React
  • run a playwright test that checks that the div has the expected text
  • do all of the above in a Github Action task

Once that baseline is there, next steps are to:

  • add more frameworks support: Vue & Svelte
  • update testing to handle multiple framework tests in parallel

Once we have multiple frameworks, we can then start to generate a ton more tests, and increase framework support gradually!

Issue Analytics

  • State:closed
  • Created a year ago
  • Reactions:1
  • Comments:5 (5 by maintainers)

github_iconTop GitHub Comments

kylecordescommented, Jun 2, 2022

Having used Storybook with various component frameworks, I’ve noticed that the config needed to deploy components in Storybook generally isn’t quite the same (certainly not bit-identical) to the config/code needed to use the components in the normal way, with no Storybook involved.

Therefore maybe think about a simpler variation?

Pile of mitosis components that exercise every feature of mitosis, and exercise any coding patterns that has revealed a bug in the past.

Compile those to all N frameworks.

Hand code the bare minimum for each of the frameworks to make it use those components - this should not be much.

Run the same Playwright test against the resulting N applications - I think this would cover all of the web targets. React Native and others may need separate support.

This would avoid having to step through the Storybook nuances for each target framework.

(Using any of the various build tools out there (Bazel, Nx, others) parallelization this should be relatively effort free.)

samijabercommented, Aug 1, 2022

Closed by a while back! 🎉

Read more comments on GitHub >

github_iconTop Results From Across the Web

What is End-to-End Testing? | E2E Testing Tools - Katalon
End-to-end testing is a technique that tests the entire software product from beginning to end to ensure the application flow behaves as expected....
Read more >
What is end-to-end testing? | CircleCI
End-to-end testing, also known as E2E testing, is a methodology used for ensuring that applications behave as expected and that the flow of ......
Read more >
What is End To End Testing? - BrowserStack
End to end testing (E2E testing) is a software testing method that involves testing an application's workflow from beginning to end. This method ......
Read more >
What is END-To-END Testing? E2E Example - Guru99
END-TO-END TESTING is a type of Software Testing that validates the software system along with its integration with external interfaces.
Read more >
What Is End-To-End Testing? - SmartBear
End-to-end testing is a methodology used in the software development lifecycle (SDLC) to test the functionality and performance of an application under ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found