github-action VS react-hooks-in-action-with-cypress

# .github/workflows/main.yml name: cypress-crud-api-test on: push: workflow_dispatch: # if this branch is pushed back to back, cancel the older branch's workflow concurrency: group: ${{ github.ref }} && ${{ github.workflow }} cancel-in-progress: true jobs: test: strategy: # uses 1 CI machine matrix: machines: [1] runs-on: ubuntu-20.04 steps: - name: Checkout 🛎 uses: actions/checkout@v2 # https://github.com/cypress-io/github-action - name: Run api tests 🧪 uses: cypress-io/[email protected] with: browser: chrome record: true group: crud api test env: CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }} LAUNCH_DARKLY_PROJECT_KEY: ${{ secrets.LAUNCH_DARKLY_PROJECT_KEY }} LAUNCH_DARKLY_AUTH_TOKEN: ${{ secrets.LAUNCH_DARKLY_AUTH_TOKEN }} LAUNCHDARKLY_SDK_KEY: ${{ secrets.LAUNCHDARKLY_SDK_KEY }} #{{ # Here we are running the unit tests after the e2e # taking advantage of npm install in Cypress GHA. # Ideally we install first, and carry over the cache # to unit and e2e jobs. # Check this link for the better way: # https://github.com/muratkeremozcan/react-hooks-in-action-with-cypress/blob/main/.github/workflows/main.yml - name: run unit tests run: npm run test

For much more info regarding the Cypress Github Action, check out their detailed documentation. I'm just barely scratching the surface of its capabilities here.

Cypress maintains a very neat GitHub Action that makes CI usage convenient with custom parameters.

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.

See other plugin file examples here and here.

Any guide is lackluster without reproducible code, so here is the full repo.

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.

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.