Our great sponsors
-
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.
-
Here is the combinatorial approach to reduce the exhaustive test suite. Paste combinatorial test (CT) model into the web app CTWedge:
-
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.
-
For Cypress component tests, we already should have cy.stub'd the feature flags. The flags work great with a served app, but in a component or unit test, there is no network call to LD; stubbing the hooks is the way to go. Mind that at the time of writing, because of issue 18552 stubbing modules isn't working in the component runner. The same thing is ok in the e2e runner. In the sample repo this will be updated with Cypress 10.
-
The cypress-ld-control plugin utilizes cy.task, which allows node code to execute within Cypress context. Therefore we will not be able to use cypress.env.json to store these LD related environment variables locally.
-
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.
-
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.
-
Here are 3 neater ways without variable assignments, showcasing TDD vs BDD assertions and our favorite; cy-spok:
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
cypress-should-really is a functional helper for Cypress, capable of a lot more than this simple usage.
-
cypress-localstorage-commands
Extends Cypress' cy commands with localStorage methods. Allows preserving localStorage between tests and spec files. Allows disabling localStorage.
Cypress clears local storage between tests — it blocks — and LD sets a random user in local storage. This works great when a spec file has a single it block, but what happens when there are multiple it blocks? We can handle that with cypress-localstorage-commands as well.
