3đź‘Ť
Could it be that the LiveServerTestCase server can only handle a single request at a time? So it hangs because it can’t deal with a request-from-within-a-request?
The source says it will “handle one request at a time”, but then again it says “without blocking”, so that’s ambiguous…
I think you’re going to be best off dropping LiveServerTestCase and just rolling your own test runner. You can use setUp to spin up runserver
in a separate process, and tearDown
to reset the database (manage.py flush
?). If you want to use a test database, you could use a different settings.py, or just move the “real” database out of the way for the duration of the test…
3đź‘Ť
The request is hanging after the test is complete because you’re making the request via the requests
library and not the official test client described here.
You don’t even need to do this though, it makes more sense to test the API directly and not spin up a web server through Django.
This is a decription of LiveServerTestCase
from the documentation here
LiveServerTestCase
launches a live Django server in the background on
setup, and shuts it down on teardown. This allows the use of automated
test clients such as, for example, the Selenium client, to execute a
series of functional tests inside a browser and simulate a real user’s
actions.
There’s no need to even initalise the Django application if you want to test the API itself.
One method for testing I like to follow for problems like this is the component integration methodology, sort of described on Wikipedia here.
In this example we would test the Django application (the front end) separately from the service layer (the API). You may still use the API’s when testing the front end, but the separation exists to define how you write the tests.
Since the API is a Flask
application, I would use Flasks built in testing tools described here.
The API has nothing to do with Django, yes it is consumed by a Django application, and that application has a hard dependency on that API, but you’re wanting to specifically test the API itself.
To aid in UI testing, you could use the API as part of your test fixture/setUp
routine to save yourself from using the UI to add any test data needed for execution. However, if you’re wanting to test the API itself then doing it through the Django client is not going to work due to the issue mentioned above.
- How to get the .env file into the remote host server
- Programmatically sync the db in Django
- What does TypeError, __init__() missing 1 required positional argument: 'get_response' mean in python?
- Apache or lighttpd
- Django cache framework. What is the difference between TIMEOUT and CACHE_MIDDLEWARE_SECONDS?