darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-07-16 11:20:12 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
4d0da6594de60fcf37dc7796279462e32072d7a1
notifications-admin/tests/app/main/views/test_user_profile.py

323 lines
9.9 KiB
Python
Raw Normal View History

Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
import json
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
import uuid
ensure other 2FA pages also handle session id specifically, the 2FA page when you first create an account is different to the login 2FA page and also the 2FA page when you change your phone number is different as well
2017-02-24 16:21:41 +00:00
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
import pytest
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
from flask import url_for
Send an email to the user when they change email address This PR changes the flow to change an email address. Once the user enter their password, they are told "Check your email". An email has been sent to them containing a link to notify which contains an encrypted token. The encrypted token contains the user id and new email address. Once the link is clicked the user's email address is updated to the new email address. They are redirected to the /user-profile page. Also in this commit is an update from flask.ext.login to flask_login.
2016-10-13 17:05:37 +01:00
from notifications_utils.url_safe_token import generate_token
define isort first party (app and tests) we were seeing isort produce different outputs locally and in docker - this was due to it having different opinions about whether the tests module (ie all our unit tests) is a first party (local) or third party (pip installed) import. It's a first party import, so by defining this in the setup.cfg isort settings, we can force it to be consistent between environments. Note: I don't know why it was different in the first place though
2018-04-25 14:12:58 +01:00
Reduce the errors related to user fixtures We were using user fixtures in a lot of parameterized tests, but this is no longer allowed in Pytest 5. To avoid having to split up the parametrized tests (which would make the test files a lot longer and slightly more difficult to read) this commit creates functions which return various types of user json so that we can use these as the test parameters instead.
2019-12-19 16:59:07 +00:00
from tests.conftest import create_api_user_active, url_for_endpoint_with_token
ensure other 2FA pages also handle session id specifically, the 2FA page when you first create an account is different to the login 2FA page and also the 2FA page when you change your phone number is different as well
2017-02-24 16:21:41 +00:00
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_show_overview_page(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
page = client_request.get(('main.user_profile'))
assert page.select_one('h1').text.strip() == 'Your profile'
change wording of platform admin toggle to positive rather than negative CHS Approved Wording :+1: also rename suppress_platform_admin -> disable_platform_admin_view in the backend, as suppress is a kinda weird word.
2019-06-14 12:32:47 +01:00
assert 'Use platform admin view' not in page
add option to suppress platform admin temporarily so that platform admins (us) can view pages as regular users do easily. Simply adds a flag in the session cookie that overrides the actual platform admin flag on the user model if set. This way it's safe, since this only downgrades existing functionality, so if someone managed to alter it they could only get less permissions, not more. You can change this value from the user profile page if either: * you're a platform admin * the flag is set (to any value) on the cookie. This slightly weird check means that we don't check the underlying `user._platform_admin` flag anywhere in the code, even when toggling the suppression.
2019-06-13 19:00:17 +01:00
change wording of platform admin toggle to positive rather than negative CHS Approved Wording :+1: also rename suppress_platform_admin -> disable_platform_admin_view in the backend, as suppress is a kinda weird word.
2019-06-14 12:32:47 +01:00
def test_overview_page_shows_disable_for_platform_admin(
add option to suppress platform admin temporarily so that platform admins (us) can view pages as regular users do easily. Simply adds a flag in the session cookie that overrides the actual platform admin flag on the user model if set. This way it's safe, since this only downgrades existing functionality, so if someone managed to alter it they could only get less permissions, not more. You can change this value from the user profile page if either: * you're a platform admin * the flag is set (to any value) on the cookie. This slightly weird check means that we don't check the underlying `user._platform_admin` flag anywhere in the code, even when toggling the suppression.
2019-06-13 19:00:17 +01:00
client_request,
platform_admin_user
):
client_request.login(platform_admin_user)
page = client_request.get(('main.user_profile'))
assert page.select_one('h1').text.strip() == 'Your profile'
change wording of platform admin toggle to positive rather than negative CHS Approved Wording :+1: also rename suppress_platform_admin -> disable_platform_admin_view in the backend, as suppress is a kinda weird word.
2019-06-14 12:32:47 +01:00
disable_platform_admin_row = page.select('tr')[-1]
assert ' '.join(disable_platform_admin_row.text.split()) == 'Use platform admin view Yes Change'
Uncomment commented-out tests Accidentally(?) introduced in 2792bece54b0cfd96b5ff666fe9cf30cd069d879
2016-05-16 10:29:58 +01:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_show_name_page(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
page = client_request.get(('main.user_profile_name'))
assert page.select_one('h1').text.strip() == 'Change your name'
Uncomment commented-out tests Accidentally(?) introduced in 2792bece54b0cfd96b5ff666fe9cf30cd069d879
2016-05-16 10:29:58 +01:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_redirect_after_name_change(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_update_user_attribute,
invite-team-members
2018-02-19 16:53:29 +00:00
mock_email_is_not_already_in_use
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request.post(
'main.user_profile_name',
_data={'new_name': 'New Name'},
_expected_status=302,
_expected_redirect=url_for('main.user_profile', _external=True),
)
assert mock_update_user_attribute.called is True
Uncomment commented-out tests Accidentally(?) introduced in 2792bece54b0cfd96b5ff666fe9cf30cd069d879
2016-05-16 10:29:58 +01:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_show_email_page(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
page = client_request.get(
'main.user_profile_email'
)
assert page.select_one('h1').text.strip() == 'Change your email address'
Uncomment commented-out tests Accidentally(?) introduced in 2792bece54b0cfd96b5ff666fe9cf30cd069d879
2016-05-16 10:29:58 +01:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_redirect_after_email_change(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_login,
invite-team-members
2018-02-19 16:53:29 +00:00
mock_email_is_not_already_in_use,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request.post(
'main.user_profile_email',
_data={'email_address': 'new_notify@notify.gov.uk'},
_expected_status=302,
_expected_redirect=url_for(
'main.user_profile_email_authenticate',
_external=True,
)
)
Uncomment commented-out tests Accidentally(?) introduced in 2792bece54b0cfd96b5ff666fe9cf30cd069d879
2016-05-16 10:29:58 +01:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_show_authenticate_after_email_change(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
with client_request.session_transaction() as session:
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
session['new-email'] = 'new_notify@notify.gov.uk'
Uncomment commented-out tests Accidentally(?) introduced in 2792bece54b0cfd96b5ff666fe9cf30cd069d879
2016-05-16 10:29:58 +01:00
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
page = client_request.get('main.user_profile_email_authenticate')
assert 'Change your email address' in page.text
assert 'Confirm' in page.text
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_render_change_email_continue_after_authenticate_email(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_verify_password,
mock_send_change_email_verification,
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
with client_request.session_transaction() as session:
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
session['new-email'] = 'new_notify@notify.gov.uk'
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
page = client_request.post(
'main.user_profile_email_authenticate',
data={'password': '12345'},
_expected_status=200,
)
assert 'Click the link in the email to confirm the change to your email address.' in page.text
Send an email to the user when they change email address This PR changes the flow to change an email address. Once the user enter their password, they are told "Check your email". An email has been sent to them containing a link to notify which contains an encrypted token. The encrypted token contains the user id and new email address. Once the link is clicked the user's email address is updated to the new email address. They are redirected to the /user-profile page. Also in this commit is an update from flask.ext.login to flask_login.
2016-10-13 17:05:37 +01:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_redirect_to_user_profile_when_user_confirms_email_link(
app_,
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
logged_in_client,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
api_user_active,
mock_update_user_attribute,
):
Send an email to the user when they change email address This PR changes the flow to change an email address. Once the user enter their password, they are told "Check your email". An email has been sent to them containing a link to notify which contains an encrypted token. The encrypted token contains the user id and new email address. Once the link is clicked the user's email address is updated to the new email address. They are redirected to the /user-profile page. Also in this commit is an update from flask.ext.login to flask_login.
2016-10-13 17:05:37 +01:00
Make user API client return JSON, not a model The data flow of other bits of our application looks like this: ``` API (returns JSON) ⬇ API client (returns a built in type, usually `dict`) ⬇ Model (returns an instance, eg of type `Service`) ⬇ View (returns HTML) ``` The user API client was architected weirdly, in that it returned a model directly, like this: ``` API (returns JSON) ⬇ API client (returns a model, of type `User`, `InvitedUser`, etc) ⬇ View (returns HTML) ``` This mixing of different layers of the application is bad because it makes it hard to write model code that doesn’t have circular dependencies. As our application gets more complicated we will be relying more on models to manage this complexity, so we should make it easy, not hard to write them. It also means that most of our mocking was of the User model, not just the underlying JSON. So it would have been easy to introduce subtle bugs to the user model, because it wasn’t being comprehensively tested. A lot of the changed lines of code in this commit mean changing the tests to mock only the JSON, which means that the model layer gets implicitly tested. For those reasons this commit changes the user API client to return JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
token = generate_token(payload=json.dumps({'user_id': api_user_active['id'], 'email': 'new_email@gov.uk'}),
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
secret=app_.config['SECRET_KEY'], salt=app_.config['DANGEROUS_SALT'])
Stop url_for double-encoding .'s in password test One of the changes this pulls in is encoding of periods in the token used for new password requests. In real-life the resulting URL is build by concatenating the base url with the token so it isn't processed further. The test for new password requests builds the URL with url_for. This encodes the result returned so the periods are encoded twice.
2018-10-18 14:34:07 +01:00
response = logged_in_client.get(url_for_endpoint_with_token('main.user_profile_email_confirm',
token=token))
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert response.status_code == 302
assert response.location == url_for('main.user_profile', _external=True)
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_show_mobile_number_page(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
page = client_request.get(('main.user_profile_mobile_number'))
assert 'Change your mobile number' in page.text
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
Let users register with int’national phone numbers Right now Notify restricts you to registering with a UK mobile number. This is because when we built the user registration stuff we couldn’t send to international mobiles. However we can send to international mobile numbers, and it’s totally reasonable to expect employees of the UK government to be working abroad, and have a foreign mobile phone – we’ve heard from one such user. So this commit: - changes all places where users enter their own phone number to use the validation function which allows international phone numbers - renames the `mobile_number` validation to `uk_mobile_number` to make it explicit, and force it to break the tests if there’s somewhere it’s being used that I haven’t thought of
2017-08-29 14:52:24 +01:00
@pytest.mark.parametrize('phone_number_to_register_with', [
'+4407700900460',
'+1800-555-555',
])
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_redirect_after_mobile_number_change(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
Let users register with int’national phone numbers Right now Notify restricts you to registering with a UK mobile number. This is because when we built the user registration stuff we couldn’t send to international mobiles. However we can send to international mobile numbers, and it’s totally reasonable to expect employees of the UK government to be working abroad, and have a foreign mobile phone – we’ve heard from one such user. So this commit: - changes all places where users enter their own phone number to use the validation function which allows international phone numbers - renames the `mobile_number` validation to `uk_mobile_number` to make it explicit, and force it to break the tests if there’s somewhere it’s being used that I haven’t thought of
2017-08-29 14:52:24 +01:00
phone_number_to_register_with,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request.post(
'main.user_profile_mobile_number',
_data={'mobile_number': phone_number_to_register_with},
_expected_status=302,
_expected_redirect=url_for(
'main.user_profile_mobile_number_authenticate',
_external=True,
)
)
with client_request.session_transaction() as session:
Let users register with int’national phone numbers Right now Notify restricts you to registering with a UK mobile number. This is because when we built the user registration stuff we couldn’t send to international mobiles. However we can send to international mobile numbers, and it’s totally reasonable to expect employees of the UK government to be working abroad, and have a foreign mobile phone – we’ve heard from one such user. So this commit: - changes all places where users enter their own phone number to use the validation function which allows international phone numbers - renames the `mobile_number` validation to `uk_mobile_number` to make it explicit, and force it to break the tests if there’s somewhere it’s being used that I haven’t thought of
2017-08-29 14:52:24 +01:00
assert session['new-mob'] == phone_number_to_register_with
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_show_authenticate_after_mobile_number_change(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
with client_request.session_transaction() as session:
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
session['new-mob'] = '+441234123123'
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
page = client_request.get(
'main.user_profile_mobile_number_authenticate',
)
assert 'Change your mobile number' in page.text
assert 'Confirm' in page.text
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_redirect_after_mobile_number_authenticate(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_verify_password,
mock_send_verify_code,
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
with client_request.session_transaction() as session:
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
session['new-mob'] = '+441234123123'
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request.post(
'main.user_profile_mobile_number_authenticate',
_data={'password': '12345667'},
_expected_status=302,
_expected_redirect=url_for(
'main.user_profile_mobile_number_confirm',
_external=True,
)
)
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_show_confirm_after_mobile_number_change(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
with client_request.session_transaction() as session:
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
session['new-mob-password-confirmed'] = True
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
page = client_request.get(
'main.user_profile_mobile_number_confirm'
)
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
assert 'Change your mobile number' in page.text
assert 'Confirm' in page.text
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
Let users register with int’national phone numbers Right now Notify restricts you to registering with a UK mobile number. This is because when we built the user registration stuff we couldn’t send to international mobiles. However we can send to international mobile numbers, and it’s totally reasonable to expect employees of the UK government to be working abroad, and have a foreign mobile phone – we’ve heard from one such user. So this commit: - changes all places where users enter their own phone number to use the validation function which allows international phone numbers - renames the `mobile_number` validation to `uk_mobile_number` to make it explicit, and force it to break the tests if there’s somewhere it’s being used that I haven’t thought of
2017-08-29 14:52:24 +01:00
@pytest.mark.parametrize('phone_number_to_register_with', [
'+4407700900460',
'+1800-555-555',
])
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_redirect_after_mobile_number_confirm(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
ensure other 2FA pages also handle session id specifically, the 2FA page when you first create an account is different to the login 2FA page and also the 2FA page when you change your phone number is different as well
2017-02-24 16:21:41 +00:00
mocker,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_update_user_attribute,
mock_check_verify_code,
Let users register with int’national phone numbers Right now Notify restricts you to registering with a UK mobile number. This is because when we built the user registration stuff we couldn’t send to international mobiles. However we can send to international mobile numbers, and it’s totally reasonable to expect employees of the UK government to be working abroad, and have a foreign mobile phone – we’ve heard from one such user. So this commit: - changes all places where users enter their own phone number to use the validation function which allows international phone numbers - renames the `mobile_number` validation to `uk_mobile_number` to make it explicit, and force it to break the tests if there’s somewhere it’s being used that I haven’t thought of
2017-08-29 14:52:24 +01:00
phone_number_to_register_with,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Reduce the errors related to user fixtures We were using user fixtures in a lot of parameterized tests, but this is no longer allowed in Pytest 5. To avoid having to split up the parametrized tests (which would make the test files a lot longer and slightly more difficult to read) this commit creates functions which return various types of user json so that we can use these as the test parameters instead.
2019-12-19 16:59:07 +00:00
user_before = create_api_user_active(with_unique_id=True)
user_after = create_api_user_active(with_unique_id=True)
Make user API client return JSON, not a model The data flow of other bits of our application looks like this: ``` API (returns JSON) ⬇ API client (returns a built in type, usually `dict`) ⬇ Model (returns an instance, eg of type `Service`) ⬇ View (returns HTML) ``` The user API client was architected weirdly, in that it returned a model directly, like this: ``` API (returns JSON) ⬇ API client (returns a model, of type `User`, `InvitedUser`, etc) ⬇ View (returns HTML) ``` This mixing of different layers of the application is bad because it makes it hard to write model code that doesn’t have circular dependencies. As our application gets more complicated we will be relying more on models to manage this complexity, so we should make it easy, not hard to write them. It also means that most of our mocking was of the User model, not just the underlying JSON. So it would have been easy to introduce subtle bugs to the user model, because it wasn’t being comprehensively tested. A lot of the changed lines of code in this commit mean changing the tests to mock only the JSON, which means that the model layer gets implicitly tested. For those reasons this commit changes the user API client to return JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
user_before['current_session_id'] = str(uuid.UUID(int=1))
user_after['current_session_id'] = str(uuid.UUID(int=2))
ensure other 2FA pages also handle session id specifically, the 2FA page when you first create an account is different to the login 2FA page and also the 2FA page when you change your phone number is different as well
2017-02-24 16:21:41 +00:00
# first time (login decorator) return normally, second time (after 2FA return with new session id)
mocker.patch('app.user_api_client.get_user', side_effect=[user_before, user_after])
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
with client_request.session_transaction() as session:
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
session['new-mob-password-confirmed'] = True
Let users register with int’national phone numbers Right now Notify restricts you to registering with a UK mobile number. This is because when we built the user registration stuff we couldn’t send to international mobiles. However we can send to international mobile numbers, and it’s totally reasonable to expect employees of the UK government to be working abroad, and have a foreign mobile phone – we’ve heard from one such user. So this commit: - changes all places where users enter their own phone number to use the validation function which allows international phone numbers - renames the `mobile_number` validation to `uk_mobile_number` to make it explicit, and force it to break the tests if there’s somewhere it’s being used that I haven’t thought of
2017-08-29 14:52:24 +01:00
session['new-mob'] = phone_number_to_register_with
Make user API client return JSON, not a model The data flow of other bits of our application looks like this: ``` API (returns JSON) ⬇ API client (returns a built in type, usually `dict`) ⬇ Model (returns an instance, eg of type `Service`) ⬇ View (returns HTML) ``` The user API client was architected weirdly, in that it returned a model directly, like this: ``` API (returns JSON) ⬇ API client (returns a model, of type `User`, `InvitedUser`, etc) ⬇ View (returns HTML) ``` This mixing of different layers of the application is bad because it makes it hard to write model code that doesn’t have circular dependencies. As our application gets more complicated we will be relying more on models to manage this complexity, so we should make it easy, not hard to write them. It also means that most of our mocking was of the User model, not just the underlying JSON. So it would have been easy to introduce subtle bugs to the user model, because it wasn’t being comprehensively tested. A lot of the changed lines of code in this commit mean changing the tests to mock only the JSON, which means that the model layer gets implicitly tested. For those reasons this commit changes the user API client to return JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
session['current_session_id'] = user_before['current_session_id']
ensure other 2FA pages also handle session id specifically, the 2FA page when you first create an account is different to the login 2FA page and also the 2FA page when you change your phone number is different as well
2017-02-24 16:21:41 +00:00
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request.post(
'main.user_profile_mobile_number_confirm',
_data={'sms_code': '12345'},
_expected_status=302,
_expected_redirect=url_for(
'main.user_profile',
_external=True,
)
)
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
ensure other 2FA pages also handle session id specifically, the 2FA page when you first create an account is different to the login 2FA page and also the 2FA page when you change your phone number is different as well
2017-02-24 16:21:41 +00:00
# make sure the current_session_id has changed to what the API returned
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
with client_request.session_transaction() as session:
Make user API client return JSON, not a model The data flow of other bits of our application looks like this: ``` API (returns JSON) ⬇ API client (returns a built in type, usually `dict`) ⬇ Model (returns an instance, eg of type `Service`) ⬇ View (returns HTML) ``` The user API client was architected weirdly, in that it returned a model directly, like this: ``` API (returns JSON) ⬇ API client (returns a model, of type `User`, `InvitedUser`, etc) ⬇ View (returns HTML) ``` This mixing of different layers of the application is bad because it makes it hard to write model code that doesn’t have circular dependencies. As our application gets more complicated we will be relying more on models to manage this complexity, so we should make it easy, not hard to write them. It also means that most of our mocking was of the User model, not just the underlying JSON. So it would have been easy to introduce subtle bugs to the user model, because it wasn’t being comprehensively tested. A lot of the changed lines of code in this commit mean changing the tests to mock only the JSON, which means that the model layer gets implicitly tested. For those reasons this commit changes the user API client to return JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
assert session['current_session_id'] == user_after['current_session_id']
ensure other 2FA pages also handle session id specifically, the 2FA page when you first create an account is different to the login 2FA page and also the 2FA page when you change your phone number is different as well
2017-02-24 16:21:41 +00:00
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_show_password_page(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
page = client_request.get(('main.user_profile_password'))
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
assert page.select_one('h1').text.strip() == 'Change your password'
Working tests, hopefully all code changes done.
2016-01-27 12:22:32 +00:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_should_redirect_after_password_change(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
Update password on user profile with new endpoint
2017-02-07 13:32:20 +00:00
mock_update_user_password,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_verify_password,
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request.post(
'main.user_profile_password',
_data={
'new_password': 'the new password',
'old_password': 'the old password',
},
_expected_status=302,
_expected_redirect=url_for(
'main.user_profile',
_external=True,
),
)
Stop non-gov user seeing/changing email and add test
2016-10-28 11:45:05 +01:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_non_gov_user_cannot_see_change_email_link(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
api_nongov_user_active,
Look in organisation for whitelisted domains At the moment we have to update a YAML file and deploy the change to get a new domain whitelisted. We already have a thing for adding new domains – the organisation stuff. This commit extends the validation to look in the `domains` table on the API if it can’t find anything in the YAML whitelist. This has the advantage of: - not having to deploy code to whitelist a new domain - forcing us to create new organisations as they come along, so that users’ services automatically get allocated to the organisation once their domain is whitelisted
2019-05-28 16:11:54 +01:00
mock_get_organisations,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request.login(api_nongov_user_active)
page = client_request.get('main.user_profile')
Change how link is referenced in user profile test Co-Authored-By: Katie Smith <klssmith@users.noreply.github.com>
2020-02-21 14:05:34 +00:00
assert not page.find('a', {'href': url_for('main.user_profile_email')})
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
assert page.select_one('h1').text.strip() == 'Your profile'
Stop non-gov user seeing/changing email and add test
2016-10-28 11:45:05 +01:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_non_gov_user_cannot_access_change_email_page(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
api_nongov_user_active,
Look in organisation for whitelisted domains At the moment we have to update a YAML file and deploy the change to get a new domain whitelisted. We already have a thing for adding new domains – the organisation stuff. This commit extends the validation to look in the `domains` table on the API if it can’t find anything in the YAML whitelist. This has the advantage of: - not having to deploy code to whitelist a new domain - forcing us to create new organisations as they come along, so that users’ services automatically get allocated to the organisation once their domain is whitelisted
2019-05-28 16:11:54 +01:00
mock_get_organisations,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request.login(api_nongov_user_active)
client_request.get('main.user_profile_email', _expected_status=403)
add option to suppress platform admin temporarily so that platform admins (us) can view pages as regular users do easily. Simply adds a flag in the session cookie that overrides the actual platform admin flag on the user model if set. This way it's safe, since this only downgrades existing functionality, so if someone managed to alter it they could only get less permissions, not more. You can change this value from the user profile page if either: * you're a platform admin * the flag is set (to any value) on the cookie. This slightly weird check means that we don't check the underlying `user._platform_admin` flag anywhere in the code, even when toggling the suppression.
2019-06-13 19:00:17 +01:00
change wording of platform admin toggle to positive rather than negative CHS Approved Wording :+1: also rename suppress_platform_admin -> disable_platform_admin_view in the backend, as suppress is a kinda weird word.
2019-06-14 12:32:47 +01:00
def test_normal_user_doesnt_see_disable_platform_admin(client_request):
client_request.get('main.user_profile_disable_platform_admin_view', _expected_status=403)
add option to suppress platform admin temporarily so that platform admins (us) can view pages as regular users do easily. Simply adds a flag in the session cookie that overrides the actual platform admin flag on the user model if set. This way it's safe, since this only downgrades existing functionality, so if someone managed to alter it they could only get less permissions, not more. You can change this value from the user profile page if either: * you're a platform admin * the flag is set (to any value) on the cookie. This slightly weird check means that we don't check the underlying `user._platform_admin` flag anywhere in the code, even when toggling the suppression.
2019-06-13 19:00:17 +01:00
change wording of platform admin toggle to positive rather than negative CHS Approved Wording :+1: also rename suppress_platform_admin -> disable_platform_admin_view in the backend, as suppress is a kinda weird word.
2019-06-14 12:32:47 +01:00
def test_platform_admin_can_see_disable_platform_admin_page(client_request, platform_admin_user):
add option to suppress platform admin temporarily so that platform admins (us) can view pages as regular users do easily. Simply adds a flag in the session cookie that overrides the actual platform admin flag on the user model if set. This way it's safe, since this only downgrades existing functionality, so if someone managed to alter it they could only get less permissions, not more. You can change this value from the user profile page if either: * you're a platform admin * the flag is set (to any value) on the cookie. This slightly weird check means that we don't check the underlying `user._platform_admin` flag anywhere in the code, even when toggling the suppression.
2019-06-13 19:00:17 +01:00
client_request.login(platform_admin_user)
change wording of platform admin toggle to positive rather than negative CHS Approved Wording :+1: also rename suppress_platform_admin -> disable_platform_admin_view in the backend, as suppress is a kinda weird word.
2019-06-14 12:32:47 +01:00
page = client_request.get('main.user_profile_disable_platform_admin_view')
add option to suppress platform admin temporarily so that platform admins (us) can view pages as regular users do easily. Simply adds a flag in the session cookie that overrides the actual platform admin flag on the user model if set. This way it's safe, since this only downgrades existing functionality, so if someone managed to alter it they could only get less permissions, not more. You can change this value from the user profile page if either: * you're a platform admin * the flag is set (to any value) on the cookie. This slightly weird check means that we don't check the underlying `user._platform_admin` flag anywhere in the code, even when toggling the suppression.
2019-06-13 19:00:17 +01:00
change wording of platform admin toggle to positive rather than negative CHS Approved Wording :+1: also rename suppress_platform_admin -> disable_platform_admin_view in the backend, as suppress is a kinda weird word.
2019-06-14 12:32:47 +01:00
assert page.select_one('h1').text.strip() == 'Use platform admin view'
assert page.select_one('input[checked]')['value'] == 'True'
add option to suppress platform admin temporarily so that platform admins (us) can view pages as regular users do easily. Simply adds a flag in the session cookie that overrides the actual platform admin flag on the user model if set. This way it's safe, since this only downgrades existing functionality, so if someone managed to alter it they could only get less permissions, not more. You can change this value from the user profile page if either: * you're a platform admin * the flag is set (to any value) on the cookie. This slightly weird check means that we don't check the underlying `user._platform_admin` flag anywhere in the code, even when toggling the suppression.
2019-06-13 19:00:17 +01:00
change wording of platform admin toggle to positive rather than negative CHS Approved Wording :+1: also rename suppress_platform_admin -> disable_platform_admin_view in the backend, as suppress is a kinda weird word.
2019-06-14 12:32:47 +01:00
def test_can_disable_platform_admin(client_request, platform_admin_user):
add option to suppress platform admin temporarily so that platform admins (us) can view pages as regular users do easily. Simply adds a flag in the session cookie that overrides the actual platform admin flag on the user model if set. This way it's safe, since this only downgrades existing functionality, so if someone managed to alter it they could only get less permissions, not more. You can change this value from the user profile page if either: * you're a platform admin * the flag is set (to any value) on the cookie. This slightly weird check means that we don't check the underlying `user._platform_admin` flag anywhere in the code, even when toggling the suppression.
2019-06-13 19:00:17 +01:00
client_request.login(platform_admin_user)
with client_request.session_transaction() as session:
change wording of platform admin toggle to positive rather than negative CHS Approved Wording :+1: also rename suppress_platform_admin -> disable_platform_admin_view in the backend, as suppress is a kinda weird word.
2019-06-14 12:32:47 +01:00
assert 'disable_platform_admin_view' not in session
add option to suppress platform admin temporarily so that platform admins (us) can view pages as regular users do easily. Simply adds a flag in the session cookie that overrides the actual platform admin flag on the user model if set. This way it's safe, since this only downgrades existing functionality, so if someone managed to alter it they could only get less permissions, not more. You can change this value from the user profile page if either: * you're a platform admin * the flag is set (to any value) on the cookie. This slightly weird check means that we don't check the underlying `user._platform_admin` flag anywhere in the code, even when toggling the suppression.
2019-06-13 19:00:17 +01:00
client_request.post(
change wording of platform admin toggle to positive rather than negative CHS Approved Wording :+1: also rename suppress_platform_admin -> disable_platform_admin_view in the backend, as suppress is a kinda weird word.
2019-06-14 12:32:47 +01:00
'main.user_profile_disable_platform_admin_view',
_data={'enabled': False},
add option to suppress platform admin temporarily so that platform admins (us) can view pages as regular users do easily. Simply adds a flag in the session cookie that overrides the actual platform admin flag on the user model if set. This way it's safe, since this only downgrades existing functionality, so if someone managed to alter it they could only get less permissions, not more. You can change this value from the user profile page if either: * you're a platform admin * the flag is set (to any value) on the cookie. This slightly weird check means that we don't check the underlying `user._platform_admin` flag anywhere in the code, even when toggling the suppression.
2019-06-13 19:00:17 +01:00
_expected_status=302,
_expected_redirect=url_for('main.user_profile', _external=True),
)
with client_request.session_transaction() as session:
change wording of platform admin toggle to positive rather than negative CHS Approved Wording :+1: also rename suppress_platform_admin -> disable_platform_admin_view in the backend, as suppress is a kinda weird word.
2019-06-14 12:32:47 +01:00
assert session['disable_platform_admin_view'] is True
add option to suppress platform admin temporarily so that platform admins (us) can view pages as regular users do easily. Simply adds a flag in the session cookie that overrides the actual platform admin flag on the user model if set. This way it's safe, since this only downgrades existing functionality, so if someone managed to alter it they could only get less permissions, not more. You can change this value from the user profile page if either: * you're a platform admin * the flag is set (to any value) on the cookie. This slightly weird check means that we don't check the underlying `user._platform_admin` flag anywhere in the code, even when toggling the suppression.
2019-06-13 19:00:17 +01:00
change wording of platform admin toggle to positive rather than negative CHS Approved Wording :+1: also rename suppress_platform_admin -> disable_platform_admin_view in the backend, as suppress is a kinda weird word.
2019-06-14 12:32:47 +01:00
def test_can_reenable_platform_admin(client_request, platform_admin_user):
add option to suppress platform admin temporarily so that platform admins (us) can view pages as regular users do easily. Simply adds a flag in the session cookie that overrides the actual platform admin flag on the user model if set. This way it's safe, since this only downgrades existing functionality, so if someone managed to alter it they could only get less permissions, not more. You can change this value from the user profile page if either: * you're a platform admin * the flag is set (to any value) on the cookie. This slightly weird check means that we don't check the underlying `user._platform_admin` flag anywhere in the code, even when toggling the suppression.
2019-06-13 19:00:17 +01:00
client_request.login(platform_admin_user)
with client_request.session_transaction() as session:
change wording of platform admin toggle to positive rather than negative CHS Approved Wording :+1: also rename suppress_platform_admin -> disable_platform_admin_view in the backend, as suppress is a kinda weird word.
2019-06-14 12:32:47 +01:00
session['disable_platform_admin_view'] = True
add option to suppress platform admin temporarily so that platform admins (us) can view pages as regular users do easily. Simply adds a flag in the session cookie that overrides the actual platform admin flag on the user model if set. This way it's safe, since this only downgrades existing functionality, so if someone managed to alter it they could only get less permissions, not more. You can change this value from the user profile page if either: * you're a platform admin * the flag is set (to any value) on the cookie. This slightly weird check means that we don't check the underlying `user._platform_admin` flag anywhere in the code, even when toggling the suppression.
2019-06-13 19:00:17 +01:00
client_request.post(
change wording of platform admin toggle to positive rather than negative CHS Approved Wording :+1: also rename suppress_platform_admin -> disable_platform_admin_view in the backend, as suppress is a kinda weird word.
2019-06-14 12:32:47 +01:00
'main.user_profile_disable_platform_admin_view',
_data={'enabled': True},
add option to suppress platform admin temporarily so that platform admins (us) can view pages as regular users do easily. Simply adds a flag in the session cookie that overrides the actual platform admin flag on the user model if set. This way it's safe, since this only downgrades existing functionality, so if someone managed to alter it they could only get less permissions, not more. You can change this value from the user profile page if either: * you're a platform admin * the flag is set (to any value) on the cookie. This slightly weird check means that we don't check the underlying `user._platform_admin` flag anywhere in the code, even when toggling the suppression.
2019-06-13 19:00:17 +01:00
_expected_status=302,
_expected_redirect=url_for('main.user_profile', _external=True),
)
with client_request.session_transaction() as session:
change wording of platform admin toggle to positive rather than negative CHS Approved Wording :+1: also rename suppress_platform_admin -> disable_platform_admin_view in the backend, as suppress is a kinda weird word.
2019-06-14 12:32:47 +01:00
assert session['disable_platform_admin_view'] is False
Reference in New Issue Copy Permalink