This is possible now we're testing letters and emails separately.
I've added a few missing cases for NHS and non-central branding.
In the next commits we'll look at the remaining special cases.
These all behave the same as each other so there's little value in
testing all of them - if we had 100 org types we wouldn't test them
all, but it's easy to get carried away when there are fewer.
We already had different functionality for email branding and will
soon be adding more for email branding pools.
Note that the "get_available_choices" class method was only used for
email branding - we can do it in the constructor for letters.
Central orgs have more options than others, including the option
to revert back to GOV.UK once branding is set. Combining the tests
together should make that a bit clearer.
All of the mock / UI assertions in these tests are covered by the
tests above them - these tests were mostly targetting which options
were being shown, which we can check at a lower level.
This is much simpler than trying to test the function via the page,
although there are still two scenarios to test there:
- The page with radio buttons (using NHS as an example).
- The page with a text form (using "other" as an example).
In future work we could split this test in two to make it clearer
what it's trying to test. For now, this keeps the diff simple.
Some tests use the `client` fixture but don’t call any of its methods.
The reason for doing this is because the test depends on something in
the request context.
This commit replaces all those instances with `client_request`, which
also sets the request context.
These tests are the last ones that still use the `client` fixture. By
replacing it with `client_request` we will be able to say that no tests
should be using the `client` fixture directly.
We have a `client_request` fixture which does a bunch of useful stuff
like:
- checking the status code of the response
- returning a `BeautifulSoup` object
Lots of our tests still use an older fixture called `client`. This is
not as good because it:
- returns a raw `Response` object
- doesn’t do the additional checks
- means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')`
This commit converts all the tests which had a `client.login(…)`
statement to use `client_request` (which is already logged in by
default).
Subsequent commits will remove uses of `client` in other tests, but
doing it this way means the work can be broken up into more manageable
chunks.
This renames the two functions we have to translate between UI and
DB permissions, as well as some of their associated variables to
make it clearer which kind of permission they contain.
These tests are unrelated to the others in test_permissions.py. We
should try and structure our tests the same as the code under test
so that it's clear where new tests should go.
Previously this was duplicated between the "two_factor" and the
"webauthn" views, and required more test setup. This DRYs up the
check and tests it once, using mocks to simplify the view tests.
As part of DRYing up the check into a util module, I've also moved
the "is_less_than_days_ago" function it uses.
Otherwise we get the following error:
________________________________________ ERROR collecting tests/app/utils/test_user.py ________________________________________
import file mismatch:
imported module 'test_user' has this __file__ attribute:
/Users/benthorner/Documents/Projects/admin/tests/app/models/test_user.py
which is not the same as the test file we want to collect:
/Users/benthorner/Documents/Projects/admin/tests/app/utils/test_user.py
HINT: remove __pycache__ / .pyc files and/or use a unique basename for your test file modules
Previously these were lumped together with integration-level tests
for specific endpoints, which test the decorator was applied to the
endpoint in question.
