Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run some unit tests on compiled bundles #9955

Closed
gaearon opened this issue Jun 14, 2017 · 6 comments
Closed

Run some unit tests on compiled bundles #9955

gaearon opened this issue Jun 14, 2017 · 6 comments

Comments

@gaearon
Copy link
Collaborator

gaearon commented Jun 14, 2017

A lot of our tests are now using only public APIs, and with #9954 this number is growing.

Soon we'll delete the Stack reconciler code, and with it we can remove some feature flags (partly responsible for non-public API calls) as well as Stack-specific tests.

We'll still have some tests that operate directly on files, but we should be in a position when we can opt in specific test files (hopefully, a growing count) into running on compiled development and production bundles. We'd only do this on CI so that we don't compromise local iteration speed.

We already have expectDev and expect separation which we use today for telling "warning only" failures on http://isfiberreadyyet.com/. But we can use it in the future for telling whether an expectation should be skipped for a PROD bundle.

We could use some help here: both with building an initial proof of concept of running some tests on CI with bundles, and with converting more tests to only use public APIs. You can search the source for // TODO: can we express this test with only public API? to find good starting points for tests that might be better written against public APIs (which is not always possible but you can try).

This is a bit open-ended and probably requires some prior knowledge of how we test things, and generally feeling comfortable with this repo. If you contributed before, this is a good issue to dive into.

@gaearon
Copy link
Collaborator Author

gaearon commented Jun 14, 2017

cc @iamdustan in case you're interested

@ksvitkovsky
Copy link
Contributor

I thought it would be better to make new PR for each suite that should be refactored, but some of them might be pretty little. So, should I try and combine them or it is ok to make 30 separate PR's? 😊

@gaearon
Copy link
Collaborator Author

gaearon commented Aug 10, 2017

Separate PRs would be easier to review.

@gaearon
Copy link
Collaborator Author

gaearon commented Oct 20, 2017

Let's track rewriting tests via public API in #11299.

@gaearon
Copy link
Collaborator Author

gaearon commented Nov 23, 2017

Sent a PR: #11633

@gaearon
Copy link
Collaborator Author

gaearon commented Nov 23, 2017

Fixed by #11633.

@gaearon gaearon closed this as completed Nov 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants