ActivityPub integration tests and Django


Django provides everything fedeproxy needs to process incoming requests. A middleware can be used to add an instance of the fedeproxy class to the request. A decorator can be added to the DRF view to verify the http signature is valid.

The requests package provides everything fedeproxy needs to send http requests, including adding the http signature.

Integration testing to verify both work well together can be done by running an APILiveServerTestCase. Using an APIClient would not work because it is not compatible with the requests package. For instance the requests auth argument has no equivalent in APIClient. It goes like this:

  •, auth=fun)
  • create the request with headers
  • call fun(prepared request) so that it can examine the request and modify it
  • send the modified http request to the url

The django test tools (APILiveServerTestCase is based on those) are not designed to support pytest fixtures. Since the preferred method to test fedeproxy is to use fixtures, tests that depend on them can only use APIClient. As a consequence, integration tests that depend on APILiveServerTestCase cannot not rely on fixtures which significantly limit the contexts in which they can be used.

The integration tests that require a live server should be limited to code paths that can be tested with Fedeproxy mocks (for instance http signatures).


Fyi I contributed some weeks ago to add tests on a Django + DRF + Tastypie application. The goal was (but not limited to) to discover the application behavior. I tried to make some efforts to rationalize api viewset testing with pytest, using class based tests. It is a bit immature but did the job.

See e.g. to see CBT in action and for the code.

It may gives some ideas. I am not expert in API testing but I didn’t seen this elsewhere.

1 Like

In the following merge request is the implementation of a feature that requires a live server. It relies on APILiveServerTestCase and does not share anything with the pytest fixture based tests. It should be fine because it is one of a kind. It is not worth the effort to figure out how to make it DRY.

Very interesting example, thanks for sharing! It will be useful if it turns out using the live server tests becomes more frequent.