For most of our Cypress tests, we have a seed for each test.a However, this might lead to a lot of different data seeds, which can become an unmaintainable spaghetti bowl. Especially for large data objects that have one or more child relations.
This quick and easy fix eliminates the problem that we're oversaturating the codebase with data seeds. I find this ideal for one-off tests or when you're not in total control of the (seeded) data.
In the following snippet, we see how we can change the username of a GitHub user in the test. The code intercepts the HTTP request to the GitHub API and uses the response in the reply method to overwrite the username.
While the above example is very trivial, this solution allows us to quickly re-use an existing seed to test a specific business requirement. For example, to create a customer with overdue payments.
We choose this solution because until recently our team was in total control of the customers' data, which encapsulates multiple domains. While it was a chore to create a new customer seed, it was just a one-time task. But now, we also had the requirement to read from a legacy system. Instead of deploying a faked legacy system with test data, we choose to reuse the existing system and to patch the incoming responses. We think this is an elegant solution that requires less work, and this way we're also not required to learn and interact with the internals of the legacy system.
Please consider supporting me if have you enjoyed this post and found it useful: