Recently, I developed a habit of reading at least two articles each night before sleep to reflect more on my career. Yesterday, Medium suggested an article from a big company. It was about how the team implemented their own end-to-end tool within the project. This reminded me of a phase in my career when everyone argued that we should develop our own technologies. At that time, I was young and foolish, but I learned that sometimes big tech companies prefer to control which technologies to use, and that makes sense to me. That's okay.

However, creating an E2E tool doesn't seem easy to me. I worked extensively with Cypress when I was involved with the Design System team, and I always liked this method of seeing what is rendered on the page and what we are testing, including behaviors, etc. But I can't deny that it's not a simple technology.

Anyway, I was thinking about how this could be a great point to include on your resume. In an interview, you might be asked, "What is one of the biggest achievements in your career?" and you could answer, "Oh, not a big deal, maybe when I worked at xxx and we implemented our own tool to test end-to-end applications…"

I was very interested in that article and read it with great excitement. It was a great piece where the author discussed the challenges that motivated them not to use Cypress and Playwright (I had never heard of the latter before, but it seems quite similar to Cypress based on his description). He mentioned four points, but I will write about one of them:

Difficulty in making calls to an alternative API endpoint without implementing custom network layer API rewrite rules.

Today, I only work with unit tests in my current project, but I spent some time resolving issues and reading Cypress documentation. I was an intern at that time, so I learned a lot from it, and I'm almost sure that Cypress can handle this problem!

So, I commented on this in the article, and I think it might not be widely known. Look, I don't think this big company didn't research this before starting to create their own library with a revolutionary perspective on end-to-end testing, but this motivated me to write about these issues and provide some basic examples of how to address them (although I really don't believe it would be helpful to them, just for general knowledge).

So, let's go to the problem: "Difficulty in making calls to an alternative API endpoint without implementing custom network layer API rewrite rules."
In this case, it's important to note that they didn't say it's impossible, just that it's difficult.

1. Intercepts

With this code, I'm intercepting requests to the specified endpoint, this allows me to mock a response inside the test. Using the "body" property provides the mock data, making the "fixture" property optional, they are useful when you want to simulate variuos responses or configure complex custom rules at network layer, "delay" and "throttleKbps" allow you to simulate network conditions, such as latency and bandwitdh limitations. This approach lets you test different scenarious without modifying the actual endpoint and enables you to apply various network conditions.

2. Enviroments Settings

Okay, this can be more difficult depending on the project you are working on, but if you have this option, you can configure different enviroments for tests and using a .env file to point the APIs to these alternative enviroments. I worked in a repository that had five enviroments, and one of them was dedicated solely to end-to-end tests. This setup depends on the needs of your project.

3. APIs Mockings

Maybe the most important point on this list (though, I really like the first one, interceptors), is that you can use a variety of API mocks to simulate any responses you want, without needing to interact with the actual endpoints, these are a countless mocking libraries available, I've used jackfranklin/test-data-bot, it's not the best but it's one option for creating mocks based on responses.

Again, I'm almost sure that this big company researched these solutions before claiming that they are difficult and incompatible with their problems. However, if you encounter issues making requests to an alternative API endpoint because you think you need to implement custom rules in your network layer, you can use interceptors to simulate responses in tests, redirect and manipulate your requests in a simple way. You can also use environment settings to configure different environments, making it easier to test in various contexts. Additionally, you can use API mocking, with or without a library, to eliminate the need to rewrite your network layer!

In a few days, I will write more about the other points in this article…

Bye!