test: add pytest and build details unit tests

[murilx]

• Added pytest
• Added pytest-django (not being used for now but expected to be added in the future)
• Run tests before pushing
• Updated the existing unit tests to use pytest instead of unittest
• Added utilities to perform django 'external' unit tests
• Added tests for BuildDetailsView as an example for the other django
  tests to be performed

Part of #943
Closes #995

How to test

• Make sure you are running the backend with poetry run python3 manage.py runserver
• Run the unit tests poetry run pytest

[MarceloRobert]

It seems that it is trying to get '/' and not finding it, is that expected?

Also, if I run pytest with the environment variables set but the backend not running it doesn't exit, but I think that it should exit.

It is also showing 40% for the buildDetails test and a deprecation warning for a certain config, is that expected?

[murilx]

@MarceloRobert

It seems that it is trying to get '/' and not finding it, is that expected?

Yes, this is intended. Maybe there's another way but my idea was to check if the server is online and for that I can hit a non-existent endpoint since it doesn't result in a connection error or timeout (the two things I'm considering as server offline). I also chose this because it's probably one of the faster ways of checking this, instead of having to wait for the server to process and return data I'm not interested in. I tried sending ICMP packets (pinging) the server, but from my experience it'll always result in a positive result, even if the server isn't running because it's on localhost (you can try running ping localhost)

Also, if I run pytest with the environment variables set but the backend not running it doesn't exit, but I think that it should exit.

This is a behavior I also saw and only happens if not all tests pass, so if there's any skips it'll continue running. I'll check if there's any flag I can pass pytest to change this behavior

It is also showing 40% for the buildDetails test and a deprecation warning for a certain config, is that expected?

40% I believe is the progress of the test suite. So if there's 5 tests in total, the first one would represent 20% of the test suite completed, an so on. I might be wrong though, I can check this further. The deprecation warning is related to another part of the source code, nothing that I added or related to what I added. For that reason I thought this should be solved in another PR. What do you think?

[MarceloRobert]

@murilx about the '/' ping, that's ok then, if there were an easy way to ping a specific port would be ideal but I think that that is good enough, just add this to the readme so other people don't get confused as I did

For the 40%, you're right, it might just be the total progress of the tests, and the deprecation warning seems to be from pydantic so I guess we can leave it to another future issue.

[WilsonNet]

rename this file to something like health-check or status-check

[murilx]

@MarceloRobert I added a note to the README, please check it out. About pytest not existing after finishing the tests, it's seems to be caused by pytest-django. I didn't find the real reason for it but pytest-django seems to be needed (tried to remove it and it resulted in some errors). I'll leave it as is for now to focus in implementing the separated classes we discussed on Slack, but I'll try to find a solution later. About the 40%, it's, in fact, the progress for all tests

[WilsonNet]

I think this is outdated since you are using requests.get now which I imagine is an http request

[WilsonNet]

@MarceloRobert

Yes, this is intended. Maybe there's another way but my idea was to check if the server is online and for that I can hit a non-existent endpoint since it doesn't result in a connection error or timeout (the two things I'm considering as server offline). I also chose this because it's probably one of the faster ways of checking this, instead of having to wait for the server to process and return data I'm not interested in. I tried sending ICMP packets (pinging) the server, but from my experience it'll always result in a positive result, even if the server isn't running because it's on localhost (you can try running ping localhost)

You can create an helthCheckView that simply returns an { status: "OK" } feels a little less hacky and it allow us to scale for other health checks

[murilx]

@WilsonNet initially tried a solution with sockets, since I didn't thought a endpoint for this should be necessary (at least at this moment). If you still think it's best we add this endpoint and do a request to it to verify if the server is online, tell me so I can update the function again

[WilsonNet]

working fine here

[Francisco2002]

Nice job!!