Improve the testing methods for invoking API requests.

Review Request #10397 — Created Jan. 30, 2019 and submitted

Information

Djblets
release-1.0.x

Reviewers

This is a rewrite of the various API invocation methods for unit tests
that simplifies them, moving all common logic to a single function
(api_call, formerly _api_func_wrapper). The various wrapper methods
now just invoke this method with some default arguments. Subclasses can
override api_call to add further logic, and the other methods will
benefit from it.

These also now allow for specifying the number of SQL queries that an
API handler was expected to have run. This is done by passing
expected_num_queries= to any of the API invocation methods.

The new methods are backwards-compatible with the old ones, so long as
the various keyword arguments (anything past path and query) weren't
passed as positional arguments. However, it does rename the query
argument to data, which makes more sense for non-GET requests. If
passed as a positional argument, nothing changes, but if passed as a
keyword argument, a warning will be emitted and the argument will be
converted.

Djblets and Review Board unit tests pass.

Summary ID
Improve the testing methods for invoking API requests.
This is a rewrite of the various API invocation methods for unit tests that simplifies them, moving all common logic to a single function (`api_call`, formerly `_api_func_wrapper`). The various wrapper methods now just invoke this method with some default arguments. Subclasses can override `api_call` to add further logic, and the other methods will benefit from it. These also now allow for specifying the number of SQL queries that an API handler was expected to have run. This is done by passing `expected_num_queries=` to any of the API invocation methods. The new methods are backwards-compatible with the old ones, so long as the various keyword arguments (anything past `path` and `query`) weren't passed as positional arguments. However, it does rename the `query` argument to `data`, which makes more sense for non-GET requests. If passed as a positional argument, nothing changes, but if passed as a keyword argument, a warning will be emitted and the argument will be converted.
fe3a16480127a130e909432ffcbed2caf8f5ba59
Description From Last Updated

The grammar in this warning is a little funky. Needs an "as" or "in" I think.

daviddavid
david
  1. 
      
  2. djblets/webapi/testing/testcases.py (Diff revision 1)
     
     

    The grammar in this warning is a little funky. Needs an "as" or "in" I think.

  3. 
      
chipx86
david
  1. Ship It!
  2. 
      
chipx86
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-1.0.x (b3f813f)
Loading...