Opened 4 years ago

Closed 11 months ago

#16087 closed Bug (fixed)

Add ResolverMatch object to test client responses.

Reported by: mrmachine Owned by: gchp
Component: Testing framework Version: 1.3
Severity: Normal Keywords: test client view url resolve reverse
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The docs say that you can use the test client to "Test that the correct view is executed for a given URL." but this doesn't seem to be possible without requiring users to perform their own resolve(), when Django has already done it and discarded the resulting ResolverMatch object.

response = client.post(some_url, some_data, follow=True)
self.assertEqual(resolve(response.request["PATH_INFO"]).url_name, 'some_url')

In my case, some_url is a view that processes some form data and redirects according to the data, and I'm testing that with some_data as input, the request is redirected to some_url. With different data, it might redirect to a different URL.

Initially I tried to use assertRedirects and response.redirect_chain to test this, but ran into trouble because I had to try and construct a URL string that would match the redirect_chain from the view function or URL name, without knowing the exact URL arguments that were used to generate the redirect URL (auto field and a hash that is unique to the newly created object).

I'd like to see Django add the ResolverMatch object directly to all test client responses, so that users can easily test that a specific view function or named URL was executed.

I guess this would be implemented similarly to the way the context and templates are added.

I think this is either a feature bug or a documentation bug. If this is not a valid feature of the test client, the docs should be clarified. I read "correct view is executed" to mean "correct view function (or class based view) is executed".

Change History (12)

comment:1 Changed 4 years ago by aaugustin

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

I think you're expected to use assertRedirects. Can't you just recover the auto field and hash values by fetching the last object from the database? If not, that's really an edge case, I'm not sure we want to modify Django for this.

comment:2 Changed 4 years ago by mrmachine

assertRedirects tells me the URLs that were used in a chain of redirects. It does not tell me the view (function or named URL) that was executed for a given request. Unless I'm reading the docs wrong (in which case this should be a doc fix), one of the goals of the test client is to allow users to verify the view that was executed for a given request.

What I want to test is, what view function or named URL was executed to generate the response for a given request. Not was an object created in the database (and it may not always be), then perform a redundant URL lookup (Django already did it when processing the request) so I can finally test if the correct view function or named URL was executed.

It would be a lot easier to write and read tests (and DRY) to simply POST your data to a URL, and verify the view function or named URL that generated the response. Django works some magic to make available a list of templatest that were used, the context, etc. Why not make the ResolverMatch object available, too?

I had a +1 on making this possible from cramm on IRC. I'm happy to take a crack at implementing this functionality OR writing a doc patch if that ends up being the decision. I just don't want to work on a fix if the core devs don't want it.

comment:3 Changed 4 years ago by aaugustin

  • Triage Stage changed from Design decision needed to Accepted

Since we have a +1 from a core developer, I'm going to accept the ticket. If you want to discuss the idea further before implementing it, you can send an email to django-developers.

comment:4 Changed 4 years ago by jacob

  • milestone 1.4 deleted

Milestone 1.4 deleted

comment:2 Changed 3 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:3 Changed 3 years ago by aaugustin

#15695 is related.

comment:4 Changed 3 years ago by mrmachine

  • Resolution set to fixed
  • Status changed from new to closed

Closing this as fixed. Since #15695 was fixed, the resolver match object is added to all requests (not only test client requests).

comment:5 Changed 3 years ago by mrmachine

  • Resolution fixed deleted
  • Status changed from closed to reopened

Sorry, it must be too early in the morning. Got my requests and responses mixed up!

comment:6 Changed 2 years ago by aaugustin

  • Status changed from reopened to new

comment:7 Changed 11 months ago by gchp

  • Owner changed from nobody to gchp
  • Status changed from new to assigned

comment:8 Changed 11 months ago by gchp

  • Has patch set

comment:9 Changed 11 months ago by Tim Graham <timograham@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

In bf743a4d571bbb7da276bc21c61f6ada5d26942c:

Fixed #16087 -- Added ResolverMatch instance to test client response.

Thanks mrmachine for the suggestion.

Note: See TracTickets for help on using tickets.
Back to Top