AssertionError: 200 != 403

Question

There is Django app and a test for it. I am receiving the error:

Traceback (most recent call last):
  File "../support/tests.py", line 17, in foo
    self.assertEqual(response.status_code, HttpResponseForbidden.status_code)
AssertionError: 200 != 403

The code for the test itself, that causes trouble is:

response = self.client.get('/support/download/bar/')
self.assertEqual(response.status_code, HttpResponseForbidden.status_code)

I don't understand the routine to diagnose this problem, where to start looking at. Browsing web for similar issue didn't help.

Looks like there is some problem with the url /support/download/bar/ ?

Answer 1

The test you are doing in your tests.py :

self.assertEqual(response.status_code, HttpResponseForbidden.status_code)

You are checking if the response when you go to the url /support/download/bar/ is a HttpResponseForbidden (code 403).

Apparently, you page successfully displays (code 200), which explains your error :

AssertionError: 200 != 403

You were expecting an error, but you got success displaying the webpage.

Answer 2

It looks like this test has detected an error in your application (or else the expectation of the test itself is in error). Your application is returning a 200 OK when the test expects a 403, which I can only assume indicates that some sort of access restriction or security measure is not working.

The first step to figuring out what's going on here is to find out why the test is expecting a 403. What is supposed to be happening? Inspect the source code and especially the middleware and decorators (that's where a lot of permissions checks happen) and inspect the test code to see if it's set up properly.

If you really don't understand why the test is checking for that or how that 403 error code is supposed to come about, you will have to do some investigating depending on where you got the code (assuming you did not write it yourself). Asking the people who wrote it, or inspecting the git commit message that added the test, or moving backwards in time in the git history until you find a point where the test was working, are all options.