react-hooks-in-action-with-cypress
as-a
react-hooks-in-action-with-cypress | as-a | |
---|---|---|
5 | 1 | |
7 | 62 | |
- | - | |
2.9 | 5.4 | |
11 months ago | 4 months ago | |
JavaScript | JavaScript | |
- | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
react-hooks-in-action-with-cypress
-
Triple combined code coverage for React Apps with Jest, Cypress component and e2e tests, using Github Actions
Given we are growing on the shoulders of giants with all these tools that enable comprehensive test strategies, what metrics can we evaluate our confidence with? Coverage is an assessment for the thoroughness or completeness of testing with respect to a model. Our model can be source code coverage, feature coverage, mutation score, combinatorial coverage, non-functional requirement coverage, anything. Although source code coverage is not a be all end all metric to pursue, we cannot deny its popularity and potency. We are used to gaining code coverage from unit tests, what if we could also gain source code coverage from Cypress e2e tests, as well as Cypress component tests?. We have had combined unit & e2e coverage for a while and bringing Cypress component testing to it is new in Cypress 10. Imagine being able to add any kind of testing of your choice for new features, and retain above 95% code coverage effortlessly. Would we need to trace every requirement to every test? How much would we have to worry about the changes we introduce while all tests pass and coverage does not regress? Let's walk through a midsize React app and showcase how to achieve that. As always, a blog is lackluster without code, so the code for this blog can be found in this repo, and the component test code coverage PR can be found here.
-
Effective Test Strategies for Deployed NodeJS Services using LaunchDarkly Feature Flags and Cypress. Part2: testing
See other plugin file examples here and here.
-
Painlessly setup Cypress & Percy with Github Actions in minutes
Any guide is lackluster without reproducible code, so here is the full repo.
-
Effective Test Strategies for Testing Front-end Applications using LaunchDarkly Feature Flags and Cypress. Part2: testing
In the repo let's try out an ui-(component)integration test that focuses on next and previous buttons for Bookables . These features are related to the feature flag prev-next-bookable. None of the features are network relevant, therefore all network calls are stubbed. We still get real calls from/to LD though.
-
Effective Test Strategies for Testing Front-end Applications using LaunchDarkly Feature Flags and Cypress. Part1: the setup
We are assuming you have been signed up, skimmed thorough Getting started and have access to the LaunchDarkly dashboard. Throughout the guide we will be using this repo, a mid-size React app with Cypress e2e, Cypress component tests, CI in GHA etc.. Mind that LD trial period is 2 weeks, therefore signing up will be required to fully reproduce the examples. A version of the app without feature flags can be checked out at the branch before-feature-flags. The PR for this post can be found at here. This example uses React SDK to setup the flags, however testing a front end application is the same regardless of the framework.
as-a
-
Effective Test Strategies for Testing Front-end Applications using LaunchDarkly Feature Flags and Cypress. Part2: testing
For our use case any method for accessing process.env will do. Gleb showed how to use as-a to make things neat. We can show a dotenv alternative, less neat but will do for a single repo use case. yarn add -D dotenv and create a gitignored .env file in the root of your project. The idea is exactly the same as cypress.env.json file; add values here for local use, gitignore and store them securely in CI.
What are some alternatives?
cypress-localstorage-commands - Extends Cypress' cy commands with localStorage methods. Allows preserving localStorage between tests and spec files. Allows disabling localStorage.
cy-spok - Playing with spok inside Cypress
cypress-skip-test - Simple commands to skip a test based on platform, browser or a url
Cypress - Fast, easy and reliable testing for anything that runs in a browser.
cypress-crud-api-test - crud testing a serverless application with Cypress api tests
cypress-ld-control - Set LaunchDarkly feature flags from Cypress tests
percy-cypress - Visual testing with Cypress and Percy
cypress-should-really - Functional helpers for constructing Cypress should callbacks
dotenv - Loads environment variables from .env for nodejs projects.