Our great sponsors
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
This is part two of a multi-part series. In the previous post we setup the flags, now we will test them. Before diving into testing feature flags, we will setup Cypress and transfer over the final CRUD e2e spec from the repo cypress-crud-api-test. That repo was featured in the blog post CRUD API testing a deployed service with Cypress. Note that the said repo and this service used to be separated - that is a known anti-pattern - and now we are combining the two in a whole. The change will provide us with the ability to use the LaunchDarkly (LD) client instance to make flag value assertions. We would not have that capability if the test code was in a separate repo than the source code, unless the common code was moved to a package & was imported to the two repos. In the real world if we had to apply that as a solution, we would want to have valuable trade-offs.
The branch prior to this work can be checked out at before-cypress-setup, and the PR for cypress setup can be found here. If you are following along, a practical way to accomplish this section is to copy over the PR.
My friend Gleb Bahmutov authored an excellent blog on testing LD with Cypress, there he revealed his new plugin cypress-ld-control. We used it in Effective Test Strategies for Front-end Applications using LaunchDarkly Feature Flags and Cypress. Part2: testing. The distinction here is using the plugin for a deployed service and the consequential test strategies.
See other plugin file examples here and here.
# .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/github-action@v3.0.2 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
We can take advantage of another one of Gleb's fantastic plugins cypress-skip-test. npm install -D @cypress/skip-test and Add the below line to cypress/support/index.js:
Related posts
- The 32+ ways of selective testing with Cypress: a unified, concise approach to selective testing in CI and local machines
- Run your Cypress Tests in a Github Workflow
- Push code with GitHub Actions to Google Cloud’s Artifact Registry
- Czym jest funkcja bezserwerowa?
- How to publish on npm with `--provenance` using Lerna-Lite