pizza-api VS cypress-crud-api-test

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.

In part1 we setup LaunchDarkly feature flags in our lambda handlers, deploy the lambda using ClaudiaJs, verify our service's behavior via VsCode REST Client and Amazon CloudWatch. In part 2 we bring in Cypress, api e2e test the feature flags, and showcase effective feature flag test strategies that can work for any deployed service. The PR for part1 of the blog series can be found at feature flag setup and test. The PR for part2 of the blog series can be found at e2e testing LD feature flags with Cypress. The branch saga through the blog series looks like the below. Once can check out these and follow along the blog, granted they have a LaunchDarkly account (2 week trial), an AWS account and familiarity with deploying lambdas.

Any blog post is lackluster without working code, so here is a PR from scratch adding esbuild to a repository with Cypress. You can find the final code on the main branch of the repository we will use in this example. Other examples can be found at tour-of-heroes-react-cypress-ts as well as a VueJS app. The framework and the bundler the framework uses are irrelevant, any repo can take advantage of cypress-esbuild-preprocessor for e2e tests.

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 code for this entire guide is available at GitHub. For learning purposes, you can check out the branch base to start from scratch and follow the guide. main has the final version of the repo. The code samples are setup to copy paste into the repo and work at every step.