When defining custom Cypress commands, we currently rely on importing a set of files that run Cypress.Commands.add(). There are some times when we would want to share some functions that do not benefit from being Cypress commands. For example, in a lot of test suites, we create a project with a name suffix based on the current unix timestamp. The main goal is to avoid name collisions and be able to replay the test with a different name. I already tried making this a Cypress command, but it causes new problems: you have to chain with .then(), which is not always ideal.

Instead, it would be nice if we could "just" share plain JavaScript functions, the way we are used to with libraries. But I'm worried that we will end up running Cypress.Commands.add() in test suites, when it is meant to be run in support/e2e.ts files. We have already imported a constant from @tuleap/cypress-utilities-support in several test suites, so it looks like it's not a problem, but nonetheless, I feel like we should play it safe and clearly separate the Cypress commands from the test suites.

To do this, I discovered in the Cypress docs that you can wrap the Commands.add() calls in a function. This lets us clearly separate things : test suites can import functions from @tuleap/cypress-utilities-support, and commands are only run in support/e2e.ts. We get to have our "library" to share functions. It also removes some coupling to the order of the imports: since some commands depend on others (for example: some commands need cy.getContains(), which is also one of our custom commands), the order of the imports could be important. With functions, only the order the functions are run in is important, the order of imports does not matter anymore, since they are side-effect free.

We should modify all the files that add Cypress commands and wrap them in "register" functions.