Checks run (2 succeeded)
flake8
passed.
JSHint
passed.
Move `BaseWebAPITestCase._login_user` to `TestCase.login_user`.
Review Request #15192 — Created July 23, 2026 and updated
Our base class for API tests has a helper that can log in the test
client, giving a couple knobs for whether the user should be an admin or
part of a local host. We really ought to be using this more broadly (as
opposed to just manually hardcoding usernames from our user fixtures),
so I've relocated it to the base test case, renamed it to be
not-private, and included a fallback for any third-party code that might
use the old name. All of our references have been updated.
Ran unit tests.
-
-
I like the idea of a centralized login function that makes some common patterns easy, but I think if we're centralizing this, we should go just a step further by:
- Optionally allowing login of explicit users (handling
LocalSiteassociations as needed). - Allowing an explicit
LocalSiteinstance, to constrain tests less and to not always require the fixtures for those tests that are managing customLocalSiteinstances.
Maybe this signature?
def login_user( self, *, admin: bool = False, local_site: (bool | LocalSite) = False, username: (str | None) = None, ) -> User: ...Then we can continue to use it as-is, but can also specify an explicit username or
LocalSiteinstance. That'll keep it more generally-useful without losing what made this convenient in API tests.The implementation would have to do the "create a proper user" steps outlined in the docstring if a
usernameor customlocal_siteis provided, of course. But it could keep existing logic so existing tests don't break. - Optionally allowing login of explicit users (handling
-