darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-07-18 05:30:21 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
4d0da6594de60fcf37dc7796279462e32072d7a1
notifications-admin/tests/app/main/views/test_add_service.py

358 lines
11 KiB
Python
Raw Normal View History

Set free SMS limit depending on organisation type Different parts of government get billed slightly differently, and there’s differences in how much money we’re allowed to give them. Think these numbers are right, but should be double checked.
2017-10-05 10:46:55 +01:00
import pytest
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
from flask import session, url_for
[WIP] Let the API return a 400 error message if the service name is a duplicate.
2017-08-07 11:30:25 +01:00
Add tests to ensure non gov user cannot see, access or create service
2016-10-28 10:48:29 +01:00
from app.utils import is_gov_user
Fix adding a service when organisation is unknown An ‘unknown’ organisation can either be: - one where we know it exists but don’t know much about it (in which case the API returns some JSON with the info we do know) - one we’ve never come across (in which case the API will return `None`) This commit fixes a bug where we were trying to access the organisation type in the latter case.
2019-05-03 13:35:52 +01:00
from tests import organisation_json
Fix mock_get_organisation_by_domain and mock_get_service_organisation This commits stops the `mock_get_organisation_by_domain` and `mock_get_service_organisation` fixtures from being called like functions.
2019-12-20 15:02:47 +00:00
from tests.conftest import normalize_spaces
Update the service name validation in the ServiceNameForm and AddServiceForm to check the email_safe version of the name against a list of all service email_from fields. Update find_all_service_names to find_all_service_email_from, which returns the email_from of all services.
2016-03-31 15:17:05 +01:00
110067722: Added endpoints for add-service Post is not complete as of yet.
2015-12-14 17:12:28 +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_non_gov_user_cannot_see_add_service_button(
client,
mock_login,
mock_get_non_govuser,
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,
mock_get_organisations_and_services_for_user,
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
):
Move relevant test, delete others The test for non-gov.uk domains adding services is still relevant, but probably makes more sense in `test_add_services.py`. The others are no longer relevant now the ‘All services’ page has gone.
2016-10-30 09:20:53 +00:00
client.login(api_nongov_user_active)
rename choose_service to choose_account
2018-03-08 16:51:53 +00:00
response = client.get(url_for('main.choose_account'))
Move relevant test, delete others The test for non-gov.uk domains adding services is still relevant, but probably makes more sense in `test_add_services.py`. The others are no longer relevant now the ‘All services’ page has gone.
2016-10-30 09:20:53 +00:00
assert 'Add a new service' not in response.get_data(as_text=True)
assert response.status_code == 200
Fix adding a service when organisation is unknown An ‘unknown’ organisation can either be: - one where we know it exists but don’t know much about it (in which case the API returns some JSON with the info we do know) - one we’ve never come across (in which case the API will return `None`) This commit fixes a bug where we were trying to access the organisation type in the latter case.
2019-05-03 13:35:52 +01:00
@pytest.mark.parametrize('org_json', (
None,
organisation_json(organisation_type=None),
))
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_get_should_render_add_service_template(
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
client_request,
Fix adding a service when organisation is unknown An ‘unknown’ organisation can either be: - one where we know it exists but don’t know much about it (in which case the API returns some JSON with the info we do know) - one we’ve never come across (in which case the API will return `None`) This commit fixes a bug where we were trying to access the organisation type in the latter case.
2019-05-03 13:35:52 +01:00
mocker,
org_json,
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
):
Fix adding a service when organisation is unknown An ‘unknown’ organisation can either be: - one where we know it exists but don’t know much about it (in which case the API returns some JSON with the info we do know) - one we’ve never come across (in which case the API will return `None`) This commit fixes a bug where we were trying to access the organisation type in the latter case.
2019-05-03 13:35:52 +01:00
mocker.patch(
'app.organisations_client.get_organisation_by_domain',
return_value=org_json,
)
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.add_service')
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
assert page.select_one('h1').text.strip() == 'About your service'
assert page.select_one('input[name=name]')['value'] == ''
assert [
label.text.strip() for label in page.select('.multiple-choice label')
] == [
'Central government',
'Local government',
Introduce new org types
2019-07-15 18:03:59 +01:00
'NHS – central government agency or public body',
Only show nhs radios if user has nhs domain email Also split local NHS into two groups following designer advice on readability.
2019-07-16 15:37:27 +01:00
'NHS Trust or Clinical Commissioning Group',
'GP practice',
Introduce new org types
2019-07-15 18:03:59 +01:00
'Emergency service',
'School or college',
'Other',
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
]
assert [
radio['value'] for radio in page.select('.multiple-choice input')
] == [
'central',
'local',
Introduce new org types
2019-07-15 18:03:59 +01:00
'nhs_central',
'nhs_local',
Add ‘GP’ as an organisation type Although their allowances are the same as what we call `nhs_local` it makes more sense to store them separately because: - we already present them as two separate choices to the user - we may want to handle them differently in the future, eg in terms of what branding choices are available to them Once the API is updated we can start passing in this new value from the admin app.
2019-08-27 16:26:50 +01:00
'nhs_gp',
Introduce new org types
2019-07-15 18:03:59 +01:00
'emergency_service',
'school_or_college',
'other',
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
]
def test_get_should_not_render_radios_if_org_type_known(
client_request,
mocker,
):
Fix mock_get_organisation_by_domain and mock_get_service_organisation This commits stops the `mock_get_organisation_by_domain` and `mock_get_service_organisation` fixtures from being called like functions.
2019-12-20 15:02:47 +00:00
mocker.patch(
'app.organisations_client.get_organisation_by_domain',
return_value=organisation_json(organisation_type='central'),
)
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
page = client_request.get('main.add_service')
assert page.select_one('h1').text.strip() == 'About your service'
assert page.select_one('input[name=name]')['value'] == ''
assert not page.select('.multiple-choice')
Add test for local auth' version of add-service
2020-07-01 11:18:20 +01:00
def test_show_different_page_if_user_org_type_is_local(
client_request,
mocker,
):
mocker.patch(
'app.organisations_client.get_organisation_by_domain',
return_value=organisation_json(organisation_type='local'),
)
page = client_request.get('main.add_service')
assert page.select_one('h1').text.strip() == 'About your service'
assert page.select_one('input[name=name]')['value'] == ''
assert page.select_one('main .govuk-body').text.strip() == (
Show different page for local org users when adding new service
2020-07-01 11:49:11 +01:00
'Give your service a name that tells users what your '
Add test for local auth' version of add-service
2020-07-01 11:18:20 +01:00
'messages are about, as well as who they’re from. For example:')
Set org type to NHS if user has NHS email address We get people signing up for Notify who work for the NHS, but whose organisation we don’t know about. For example `name@gloshospitals.nhs.uk` will be someone working for Gloucestershire Hospitals NHS Foundation Trust, which is not an organisation we have in the database. Currently we rely on knowing the specific organisation (NHS as a whole isn’t an organisation) in order to set the organisation type for any services they create. This commit adds a special case for anyone with an NHS email address to set the organisation type to be NHS, even when we don’t know which specific part of the NHS they work for. This is the same thing we do on the API side for NHS email and letter branding: https://github.com/alphagov/notifications-api/blob/a4ae5a0a90494ab338561010ed279bf198b15a72/app/dao/services_dao.py#L310-L313
2019-05-07 10:31:16 +01:00
@pytest.mark.parametrize('email_address', (
# User’s email address doesn’t matter when the organisation is known
'test@example.gov.uk',
'test@example.nhs.uk',
))
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
@pytest.mark.parametrize('inherited, posted, persisted, sms_limit', (
(None, 'central', 'central', 250000),
Set free allowance for GP surgeries This also tests that a user from an unknown organisation can pick any of the available options and get the right allowance.
2019-08-29 17:45:17 +01:00
(None, 'nhs_central', 'nhs_central', 250000),
(None, 'nhs_gp', 'nhs_gp', 25000),
(None, 'nhs_local', 'nhs_local', 25000),
(None, 'local', 'local', 25000),
(None, 'emergency_service', 'emergency_service', 25000),
(None, 'school_or_college', 'school_or_college', 25000),
(None, 'other', 'other', 25000),
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
('central', None, 'central', 250000),
Introduce new org types
2019-07-15 18:03:59 +01:00
('nhs_central', None, 'nhs_central', 250000),
('nhs_local', None, 'nhs_local', 25000),
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
('local', None, 'local', 25000),
Introduce new org types
2019-07-15 18:03:59 +01:00
('emergency_service', None, 'emergency_service', 25000),
('school_or_college', None, 'school_or_college', 25000),
('other', None, 'other', 25000),
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
('central', 'local', 'central', 250000),
))
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_add_service_and_redirect_to_tour_when_no_services(
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
mocker,
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_create_service,
mock_create_service_template,
mock_get_services_with_no_services,
api_user_active,
Use annual_billing tables at backend for getting and updating free_sms_fragment_limit
2017-10-31 11:22:57 +00:00
mock_create_or_update_free_sms_fragment_limit,
Assign email branding based on user’s email domain When a user creates a service we can take a pretty good guess at what organisation they’re from. For many organisations, especially local councils, GOV.UK branding is not appropriate for their service. But right now every service: - gets created with GOV.UK branding - has to ask us to change it, even if they’ve already done so for other services they run This commit starts using the `domain` field on the email branding table to lookup what email branding to assign to a service automatically, where we’re sure there’s a sensible default.
2018-09-03 11:46:41 +01:00
mock_get_all_email_branding,
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
inherited,
Set org type to NHS if user has NHS email address We get people signing up for Notify who work for the NHS, but whose organisation we don’t know about. For example `name@gloshospitals.nhs.uk` will be someone working for Gloucestershire Hospitals NHS Foundation Trust, which is not an organisation we have in the database. Currently we rely on knowing the specific organisation (NHS as a whole isn’t an organisation) in order to set the organisation type for any services they create. This commit adds a special case for anyone with an NHS email address to set the organisation type to be NHS, even when we don’t know which specific part of the NHS they work for. This is the same thing we do on the API side for NHS email and letter branding: https://github.com/alphagov/notifications-api/blob/a4ae5a0a90494ab338561010ed279bf198b15a72/app/dao/services_dao.py#L310-L313
2019-05-07 10:31:16 +01:00
email_address,
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
posted,
persisted,
sms_limit,
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
):
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
api_user_active['email_address'] = email_address
Set org type to NHS if user has NHS email address We get people signing up for Notify who work for the NHS, but whose organisation we don’t know about. For example `name@gloshospitals.nhs.uk` will be someone working for Gloucestershire Hospitals NHS Foundation Trust, which is not an organisation we have in the database. Currently we rely on knowing the specific organisation (NHS as a whole isn’t an organisation) in order to set the organisation type for any services they create. This commit adds a special case for anyone with an NHS email address to set the organisation type to be NHS, even when we don’t know which specific part of the NHS they work for. This is the same thing we do on the API side for NHS email and letter branding: https://github.com/alphagov/notifications-api/blob/a4ae5a0a90494ab338561010ed279bf198b15a72/app/dao/services_dao.py#L310-L313
2019-05-07 10:31:16 +01:00
client_request.login(api_user_active)
Fix mock_get_organisation_by_domain and mock_get_service_organisation This commits stops the `mock_get_organisation_by_domain` and `mock_get_service_organisation` fixtures from being called like functions.
2019-12-20 15:02:47 +00:00
mocker.patch(
'app.organisations_client.get_organisation_by_domain',
return_value=organisation_json(organisation_type=inherited),
)
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.add_service',
_data={
Collect organisation type So that we can default services to their appropriate text allowance, we need to find out what sector they're in. So let's start collecting that from teams as they create new services. I think Central/Local/NHS are the right options, but these can be easily changed if not.
2017-10-04 11:49:32 +01:00
'name': 'testing the post',
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
'organisation_type': posted,
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
},
_expected_status=302,
_expected_redirect=url_for(
'main.start_tour',
service_id=101,
template_id="Example%20text%20message%20template",
_external=True,
),
Collect organisation type So that we can default services to their appropriate text allowance, we need to find out what sector they're in. So let's start collecting that from teams as they create new services. I think Central/Local/NHS are the right options, but these can be easily changed if not.
2017-10-04 11:49:32 +01:00
)
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert mock_get_services_with_no_services.called
mock_create_service.assert_called_once_with(
Revert "Remove keyword args from call to create service" This reverts commit bde696cf56d86fc78ecb2b80df7e710d730ec24b. The caching decorator supports keyword arguments now.
2018-04-19 14:01:45 +01:00
service_name='testing the post',
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
organisation_type=persisted,
message_limit=50,
Revert "Remove keyword args from call to create service" This reverts commit bde696cf56d86fc78ecb2b80df7e710d730ec24b. The caching decorator supports keyword arguments now.
2018-04-19 14:01:45 +01:00
restricted=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_id=api_user_active['id'],
Pass service domain to api when adding a new service We need to pass the domain to api when adding a service so that api can link the domain of the service with a letter brand.
2019-02-12 14:02:21 +00:00
email_from='testing.the.post',
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
)
Make example text message template priority The tour teaches you how Notify works by letting you do a thing and then showing you the effect of the thing you’ve just done – a text message on your phone. This is not as effective if you don’t get the text message quickly. It breaks the association you make between what you’ve done on the computer and what’s happening on your phone. Slow text message delivery can happen if you’re doing a big job. We can get around this by making your text message use the priority queue. This was observed in the pilot research session yesterday.
2017-03-09 10:30:19 +00:00
mock_create_service_template.assert_called_once_with(
'Example text message template',
'sms',
(
'Hey ((name)), I’m trying out Notify. Today is '
'((day of week)) and my favourite colour is ((colour)).'
),
101,
)
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert session['service_id'] == 101
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
mock_create_or_update_free_sms_fragment_limit.assert_called_once_with(101, sms_limit)
110067722: Add form validation for duplicate service name.
2015-12-15 10:17:43 +00:00
Check that users have to choose an org type If we can’t guess a user’s organisation then they have to choose what type of organisation they work for when they add a new service. This commit adds a test to make sure they can’t just click the green button and proceed without picking one.
2019-05-15 16:16:23 +01:00
def test_add_service_has_to_choose_org_type(
mocker,
client_request,
mock_create_service,
mock_create_service_template,
mock_get_services_with_no_services,
api_user_active,
mock_create_or_update_free_sms_fragment_limit,
mock_get_all_email_branding,
):
mocker.patch(
'app.organisations_client.get_organisation_by_domain',
return_value=None,
)
page = client_request.post(
'main.add_service',
_data={
'name': 'testing the post',
},
_expected_status=200,
)
assert normalize_spaces(page.select_one('.error-message').text) == (
Bump WTForms to 2.3.1 This involves three changes which broke our code. To validate email addresses, the optional dependency `email-validator` must be installed<sup>1</sup>. But since we don’t use WTForms’ email validation, we shouldn’t need to subclass it – it can just be its own self contained thing. Then we don’t need to add the extra dependency. When rendering textareas, and extra `\r\n` is inserted at the beginning <sup>2</sup>. Browsers will strip this when displaying the textbox and submitting the form, but some of our tests need updating to account for this. The error message for when you don’t choose an option from some radio buttons has now changed. Rather than just accepting WTForms’ new message, this commit makes the error messages like the examples from the Design System<sup>3</sup>. By default it will say ‘Select an option’, but by passing in an extra parameter (`thing`) it can be customised to be more specific, for example ‘Select a type of organisation’. *** 1. https://github.com/wtforms/wtforms/pull/429 2. https://github.com/wtforms/wtforms/issues/238 3. https://design-system.service.gov.uk/components/radios/#error-messages
2020-04-22 17:49:03 +01:00
'Select the type of organisation'
Check that users have to choose an org type If we can’t guess a user’s organisation then they have to choose what type of organisation they work for when they add a new service. This commit adds a test to make sure they can’t just click the green button and proceed without picking one.
2019-05-15 16:16:23 +01:00
)
assert mock_create_service.called is False
assert mock_create_service_template.called is False
assert mock_create_or_update_free_sms_fragment_limit.called is False
Set org type to NHS if user has NHS email address We get people signing up for Notify who work for the NHS, but whose organisation we don’t know about. For example `name@gloshospitals.nhs.uk` will be someone working for Gloucestershire Hospitals NHS Foundation Trust, which is not an organisation we have in the database. Currently we rely on knowing the specific organisation (NHS as a whole isn’t an organisation) in order to set the organisation type for any services they create. This commit adds a special case for anyone with an NHS email address to set the organisation type to be NHS, even when we don’t know which specific part of the NHS they work for. This is the same thing we do on the API side for NHS email and letter branding: https://github.com/alphagov/notifications-api/blob/a4ae5a0a90494ab338561010ed279bf198b15a72/app/dao/services_dao.py#L310-L313
2019-05-07 10:31:16 +01:00
@pytest.mark.parametrize('email_address', (
'test@nhs.net',
'test@nhs.uk',
'test@example.NhS.uK',
'test@EXAMPLE.NHS.NET',
))
Only show nhs radios if user has nhs domain email Also split local NHS into two groups following designer advice on readability.
2019-07-16 15:37:27 +01:00
def test_get_should_only_show_nhs_org_types_radios_if_user_has_nhs_email(
Set org type to NHS if user has NHS email address We get people signing up for Notify who work for the NHS, but whose organisation we don’t know about. For example `name@gloshospitals.nhs.uk` will be someone working for Gloucestershire Hospitals NHS Foundation Trust, which is not an organisation we have in the database. Currently we rely on knowing the specific organisation (NHS as a whole isn’t an organisation) in order to set the organisation type for any services they create. This commit adds a special case for anyone with an NHS email address to set the organisation type to be NHS, even when we don’t know which specific part of the NHS they work for. This is the same thing we do on the API side for NHS email and letter branding: https://github.com/alphagov/notifications-api/blob/a4ae5a0a90494ab338561010ed279bf198b15a72/app/dao/services_dao.py#L310-L313
2019-05-07 10:31:16 +01:00
client_request,
Only show nhs radios if user has nhs domain email Also split local NHS into two groups following designer advice on readability.
2019-07-16 15:37:27 +01:00
mocker,
Set org type to NHS if user has NHS email address We get people signing up for Notify who work for the NHS, but whose organisation we don’t know about. For example `name@gloshospitals.nhs.uk` will be someone working for Gloucestershire Hospitals NHS Foundation Trust, which is not an organisation we have in the database. Currently we rely on knowing the specific organisation (NHS as a whole isn’t an organisation) in order to set the organisation type for any services they create. This commit adds a special case for anyone with an NHS email address to set the organisation type to be NHS, even when we don’t know which specific part of the NHS they work for. This is the same thing we do on the API side for NHS email and letter branding: https://github.com/alphagov/notifications-api/blob/a4ae5a0a90494ab338561010ed279bf198b15a72/app/dao/services_dao.py#L310-L313
2019-05-07 10:31:16 +01:00
api_user_active,
email_address,
):
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
api_user_active['email_address'] = email_address
Set org type to NHS if user has NHS email address We get people signing up for Notify who work for the NHS, but whose organisation we don’t know about. For example `name@gloshospitals.nhs.uk` will be someone working for Gloucestershire Hospitals NHS Foundation Trust, which is not an organisation we have in the database. Currently we rely on knowing the specific organisation (NHS as a whole isn’t an organisation) in order to set the organisation type for any services they create. This commit adds a special case for anyone with an NHS email address to set the organisation type to be NHS, even when we don’t know which specific part of the NHS they work for. This is the same thing we do on the API side for NHS email and letter branding: https://github.com/alphagov/notifications-api/blob/a4ae5a0a90494ab338561010ed279bf198b15a72/app/dao/services_dao.py#L310-L313
2019-05-07 10:31:16 +01:00
client_request.login(api_user_active)
mocker.patch(
'app.organisations_client.get_organisation_by_domain',
return_value=None,
)
Only show nhs radios if user has nhs domain email Also split local NHS into two groups following designer advice on readability.
2019-07-16 15:37:27 +01:00
page = client_request.get('main.add_service')
assert page.select_one('h1').text.strip() == 'About your service'
assert page.select_one('input[name=name]')['value'] == ''
assert [
label.text.strip() for label in page.select('.multiple-choice label')
] == [
'NHS – central government agency or public body',
'NHS Trust or Clinical Commissioning Group',
'GP practice',
]
assert [
radio['value'] for radio in page.select('.multiple-choice input')
] == [
'nhs_central',
'nhs_local',
Add ‘GP’ as an organisation type Although their allowances are the same as what we call `nhs_local` it makes more sense to store them separately because: - we already present them as two separate choices to the user - we may want to handle them differently in the future, eg in terms of what branding choices are available to them Once the API is updated we can start passing in this new value from the admin app.
2019-08-27 16:26:50 +01:00
'nhs_gp',
Only show nhs radios if user has nhs domain email Also split local NHS into two groups following designer advice on readability.
2019-07-16 15:37:27 +01:00
]
Set org type to NHS if user has NHS email address We get people signing up for Notify who work for the NHS, but whose organisation we don’t know about. For example `name@gloshospitals.nhs.uk` will be someone working for Gloucestershire Hospitals NHS Foundation Trust, which is not an organisation we have in the database. Currently we rely on knowing the specific organisation (NHS as a whole isn’t an organisation) in order to set the organisation type for any services they create. This commit adds a special case for anyone with an NHS email address to set the organisation type to be NHS, even when we don’t know which specific part of the NHS they work for. This is the same thing we do on the API side for NHS email and letter branding: https://github.com/alphagov/notifications-api/blob/a4ae5a0a90494ab338561010ed279bf198b15a72/app/dao/services_dao.py#L310-L313
2019-05-07 10:31:16 +01:00
Stop trying to infer branding when adding services The API handles this now.
2019-04-04 11:15:42 +01:00
@pytest.mark.parametrize('organisation_type, free_allowance', [
('central', 250 * 1000),
('local', 25 * 1000),
Introduce new org types
2019-07-15 18:03:59 +01:00
('nhs_central', 250 * 1000),
('nhs_local', 25 * 1000),
('school_or_college', 25 * 1000),
('emergency_service', 25 * 1000),
('other', 25 * 1000),
Set free SMS limit depending on organisation type Different parts of government get billed slightly differently, and there’s differences in how much money we’re allowed to give them. Think these numbers are right, but should be double checked.
2017-10-05 10:46:55 +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_add_service_and_redirect_to_dashboard_when_existing_service(
app_,
Cache organisation name in Redis A lot of pages in the admin app are now generated entirely from Redis, without touching the API. The one remaining API call that a lot of pages make, when the user is platform admin or a member of an organisation, is to get the name of the current service’s organisation. This commit adds some code to start caching that as well, which should speed up page load times for when we’re clicking around the admin app (it’s typically 100ms just to get the organisation, and more than that when the API is under load). This means changing the service model to get the organisation from the API by ID, not by service ID. Otherwise it would be very hard to clear the cache if the name of the organisation ever changed. We can’t cache the whole organisation because it has a `count_of_live_services` field which can change at any time, without an update being made.
2020-03-20 08:42:33 +00:00
mocker,
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_create_service,
mock_create_service_template,
mock_get_services,
Cache organisation name in Redis A lot of pages in the admin app are now generated entirely from Redis, without touching the API. The one remaining API call that a lot of pages make, when the user is platform admin or a member of an organisation, is to get the name of the current service’s organisation. This commit adds some code to start caching that as well, which should speed up page load times for when we’re clicking around the admin app (it’s typically 100ms just to get the organisation, and more than that when the API is under load). This means changing the service model to get the organisation from the API by ID, not by service ID. Otherwise it would be very hard to clear the cache if the name of the organisation ever changed. We can’t cache the whole organisation because it has a `count_of_live_services` field which can change at any time, without an update being made.
2020-03-20 08:42:33 +00:00
mock_get_no_organisation_by_domain,
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,
Set free SMS limit depending on organisation type Different parts of government get billed slightly differently, and there’s differences in how much money we’re allowed to give them. Think these numbers are right, but should be double checked.
2017-10-05 10:46:55 +01:00
organisation_type,
free_allowance,
Assign email branding based on user’s email domain When a user creates a service we can take a pretty good guess at what organisation they’re from. For many organisations, especially local councils, GOV.UK branding is not appropriate for their service. But right now every service: - gets created with GOV.UK branding - has to ask us to change it, even if they’ve already done so for other services they run This commit starts using the `domain` field on the email branding table to lookup what email branding to assign to a service automatically, where we’re sure there’s a sensible default.
2018-09-03 11:46:41 +01:00
mock_create_or_update_free_sms_fragment_limit,
mock_get_all_email_branding,
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.add_service',
_data={
Collect organisation type So that we can default services to their appropriate text allowance, we need to find out what sector they're in. So let's start collecting that from teams as they create new services. I think Central/Local/NHS are the right options, but these can be easily changed if not.
2017-10-04 11:49:32 +01:00
'name': 'testing the post',
Set free SMS limit depending on organisation type Different parts of government get billed slightly differently, and there’s differences in how much money we’re allowed to give them. Think these numbers are right, but should be double checked.
2017-10-05 10:46:55 +01:00
'organisation_type': organisation_type,
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
},
_expected_status=302,
_expected_redirect=url_for(
'main.service_dashboard',
service_id=101,
_external=True,
)
Collect organisation type So that we can default services to their appropriate text allowance, we need to find out what sector they're in. So let's start collecting that from teams as they create new services. I think Central/Local/NHS are the right options, but these can be easily changed if not.
2017-10-04 11:49:32 +01:00
)
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert mock_get_services.called
mock_create_service.assert_called_once_with(
Revert "Remove keyword args from call to create service" This reverts commit bde696cf56d86fc78ecb2b80df7e710d730ec24b. The caching decorator supports keyword arguments now.
2018-04-19 14:01:45 +01:00
service_name='testing the post',
organisation_type=organisation_type,
message_limit=app_.config['DEFAULT_SERVICE_LIMIT'],
restricted=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_id=api_user_active['id'],
Pass service domain to api when adding a new service We need to pass the domain to api when adding a service so that api can link the domain of the service with a letter brand.
2019-02-12 14:02:21 +00:00
email_from='testing.the.post',
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
)
update free sms fragment limit to go via billing client instead of service
2017-12-04 16:03:11 +00:00
mock_create_or_update_free_sms_fragment_limit.assert_called_once_with(101, free_allowance)
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert len(mock_create_service_template.call_args_list) == 0
assert session['service_id'] == 101
Redirect to dashboard if this isn't the first service There's no need to show the tour again if the user has previously created a service so just redirect to the dashboard instead.
2016-04-28 16:44:12 +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_return_form_errors_when_service_name_is_empty(
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
client_request,
mock_get_organisation_by_domain,
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.post(
'main.add_service',
data={},
_expected_status=200,
)
Replace can't with cannot
2019-09-13 10:15:05 +01:00
assert 'Cannot be empty' in page.text
Test add service completed.
2016-01-15 16:10:24 +00:00
Validate service and organisation name
2019-11-08 17:12:32 +00:00
def test_add_service_fails_if_service_name_has_less_than_2_alphanumeric_characters(
client_request,
mock_get_organisation_by_domain,
):
page = client_request.post(
'main.add_service',
data={"name": "."},
_expected_status=200,
)
assert page.find("span", {"class": "error-message"})
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_return_form_errors_with_duplicate_service_name_regardless_of_case(
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,
[WIP] Let the API return a 400 error message if the service name is a duplicate.
2017-08-07 11:30:25 +01:00
mock_create_duplicate_service,
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it
2019-04-18 12:44:18 +01:00
mock_get_organisation_by_domain,
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.post(
'main.add_service',
_data={
Collect organisation type So that we can default services to their appropriate text allowance, we need to find out what sector they're in. So let's start collecting that from teams as they create new services. I think Central/Local/NHS are the right options, but these can be easily changed if not.
2017-10-04 11:49:32 +01:00
'name': 'SERVICE ONE',
'organisation_type': 'central',
},
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
_expected_status=200,
)
assert page.select_one('.error-message').text.strip() == (
'This service name is already in use'
Collect organisation type So that we can default services to their appropriate text allowance, we need to find out what sector they're in. So let's start collecting that from teams as they create new services. I think Central/Local/NHS are the right options, but these can be easily changed if not.
2017-10-04 11:49:32 +01:00
)
Abort 403 if nonwhitelist user tries to add service
2016-10-25 18:11:37 +01:00
Correct whitelist to non-government in test name See c31264d4c for why ‘whitelist’ should be avoided. The use of whitelist here was not referring to the user-maintained list, but to mean ‘not a government’ email address. This commit renames these tests to make that difference clear.
2020-06-12 09:15:23 +01:00
def test_non_government_user_cannot_access_create_service_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
mock_get_non_govuser,
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
):
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 is_gov_user(api_nongov_user_active['email_address']) is False
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.get(
'main.add_service',
_expected_status=403,
)
Add tests to ensure non gov user cannot see, access or create service
2016-10-28 10:48:29 +01:00
Correct whitelist to non-government in test name See c31264d4c for why ‘whitelist’ should be avoided. The use of whitelist here was not referring to the user-maintained list, but to mean ‘not a government’ email address. This commit renames these tests to make that difference clear.
2020-06-12 09:15:23 +01:00
def test_non_government_user_cannot_create_service(
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_get_non_govuser,
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
):
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 is_gov_user(api_nongov_user_active['email_address']) is False
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.add_service',
_data={'name': 'SERVICE TWO'},
_expected_status=403,
)
Reference in New Issue Copy Permalink