Increase test coverage backend

[metemaddar]

Goal of this issue

Add the tests which are mentioned.
These tests are mentioned by TODO inside tests directory.

Resources

List of TODOs:

Tasks

Preview Give feedback

1. API Test Customizations #1840
   API Testing +2
   
2. API Test Isochrones #1841
   API Testing +2
   
3. API Test Scenarios #1842
   +0
   
4. Write API tests for Heatmaps #1281
   +0
5. Add a test coverage library #1793
   +0
   
6. Test for Heatmap Endpoint #1946
   API Testing +2
   

Deliverables

Branch to derive

dev

[metemaddar]

Moved from issue #1946

• As Majk Suggests, we can use the Celery test doc for testing without workers running.
• For Heatmaps as we need the Cache data, Majk suggests to run data preparation test before testing heatmaps. So we will have the heatmap data.
• For testing scheduled endpoints, we need to avoid running them at the same time, as the endpoint may be busy with another long time taking task.
• But as we are testing against python endpoint, we have the boilerplate at endpoint, we can reduce the vs-code tester workers to 1
• We also need to set this at runners configurations.

[metemaddar]

The Tests are now sequential by 6878c2d

I'm trying to make tests independent from REDIS (Results backend) if possible.

[metemaddar]

The indicators async implementation was done 8c6f732. And there were a concern about the client for if the async/await of JavaScript still makes CPU busy and hot. Fortunately as ChatGPT says, it will not block the CPU. So we can implement the indicators without set/result endpoints, and at the client side we can get the results asynchronously on one request.

From Chat GPT:

The async/await syntax in JavaScript is used to write asynchronous code that runs concurrently without blocking the execution of other tasks. It does not necessarily make the CPU busy and hot, but it depends on the implementation of the asynchronous tasks and how they are scheduled.

In general, asynchronous tasks such as network I/O or disk I/O operations are non-blocking and do not consume CPU resources while waiting for the operation to complete. Instead, the operating system or runtime environment handles the task and signals the application when the operation is complete.