I am currently working on integrating Cypress e2e tests in our existing CI/CD pipeline (I'm not an automation engineer but a developer). Our application is a fintech app which involves the typical process of registering a new business, and after the business has been registered, to go through the process of requesting a credit with it.

So far we only have a few e2e tests for registering the business, which are fine. And then we are creating a few e2e tests for the business credit request flow. But then, we want to create other tests that comprises the whole flow of creating a business + requesting a credit. However I'm just wondering what is the best way to reuse the code from the tests where the business is created instead of repeating the code in the new tests.

Just wondering what is the most elegant way to do it, either if Cypress itself offers some sort of functionality to reuse that, or just encapsulate the test code in utility functions that can be called from several tests.

1 Answer 1


Test Data Management And Dependencies

This is typically the 2nd major challenge in automation. Once the organization is convinced of the value of automated tests the next challenge is data management.

In all the organizations that I have worked in, the same challenges comes up - dependencies for authentication, authorization and the specific artifacts needed in the product, such as account, site, organization, etc. It is solved differently for manual testing where either the user registers each time as part of the testing or the organization establishes test accounts with access usually set up once and then used repeatedly going forward.

Automation for test cases that have dependencies such as authentication, authorization and other artifacts creation require new approaches that are only relevant to automation.

Thus the process for testing 'after a typical login' - or other 'setup' activities are complex for automation.

Here are some of the options:

  • Mocking and stubbing for the authentication or code that relies on it
  • Scripts that do logins using the UI
  • Permanent accounts used for test automation cases only
  • Accounts that are created through an API specifically for testing

My recommendation is mocking and stubbing and/or the ability to create or use accounts specifically for automation. This can be categorized as grey box testing, where you don't know the internals but you do have appropriate hooks for testing purposes.

One aspect you will want to master is not only creating, but deleting the artifacts once the specific test has run. Without this automation you will soon create thousands of artifacts and that will become a problem. Similar to artifacts creation, you'll want to do this through API calls and not by using the UI which is slow and unreliable.

My least favored option is creating the account through the UI, e.g. the login tests. UI automation is slow, often doesn't scale and always has elements of flakiness and thus should be avoided as a dependency for running other automation. It will frequently work OK for the first couple of test cases but then as you scale testing with more cases it typically breaks down with flaky failures and slow feedback from the test suite.

  • Thanks for the detailed explanation. Just to clarify, when I was talking about "creating/registering a business", it is apart from user authn/authz (that is managed using auth0 and we will use a hardcoded user (not hardcoded but set up via pipeline secrets). But as you said, this falls under the "other 'setup' activities" that will happen on almost every integration test. Just wondering the best approach. I can create a function that contains the cypress code that registers a business, and call that code from every integration test. Just wondering if it is the common/recommended approach. Commented Jun 26, 2023 at 20:57
  • Thanks. I consider setup more generally. While authorization and authentication are particular implementations the general issue to solve is to create an account / user / organization, etc. Essentially a thing that all the other tests need as a prerequisite or dependency for them. Under this, more broad umbrella the same needs arise and the same options to solve them exist. Commented Jun 27, 2023 at 10:29
  • Updated answer to broaden to include all artifacts. not just authentication and authorization Commented Jun 27, 2023 at 10:43
  • I suggest replacing the cypress function ('cypress code that registers a business) with a direct call to the API. This will require programming and typically using Promises. Updated answer about deleting the dependency once test is run which is important. Commented Jun 27, 2023 at 10:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.