darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-09-05 16:28:24 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
618c2eb6bb83ffa9eeff0d11336385a62fdce16e
notifications-admin/tests/app/main/views/test_jobs.py

458 lines
14 KiB
Python
Raw Normal View History

add tests for get_status_filters
2016-07-20 16:18:04 +01:00
import json
Use time to determine why notifications don’t exist Notifications won’t exist for a job if: - it’s just started - it started a long time ago (older than the retention period) We have a bug where: 1. Job starts processing, puts notifications on queue 2. Job finishes processing, sets status to `finished` 3. First notification gets picked up off the queue and put in the database In between 2. and 3. it’s possible for a job to be finished, but also to have no notifications. We’re saying this is because the notifications have been deleted, whereas really it’s because they haven’t been created yet. This commit fixes that bug by introducing the concept of recency for jobs. ‘Recent’ is defined as 1 day, which is: - a lot longer than it takes to create any notifications - a bit shorter than anyone’s retention time N.B. `processing_started` is defined here: https://github.com/alphagov/notifications-api/blob/879ba1d5f092dbf6e15bf9adadd53e4657660490/app/models.py#L1194 It can be `None` for scheduled jobs that haven’t started yet.
2020-01-16 16:58:26 +00:00
from datetime import datetime, timezone
User can cancel a letter job - happy path
2019-06-18 15:52:29 +01:00
Letter job can't be cancelled if already printed Non-cancellable letter statuses mean that it's too late to cancel a job
2019-06-18 18:00:36 +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 url_for
from freezegun import freeze_time
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
from app.main.views.jobs import get_time_left
code cleanup
2022-11-28 15:53:56 -05:00
from tests import job_json, sample_uuid, user_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
from tests.conftest import (
SERVICE_ONE_ID,
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
create_active_caseworking_user,
create_active_user_with_permissions,
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
normalize_spaces,
)
add tests for get_status_filters
2016-07-20 16:18:04 +01:00
Add unit tests for activity (and SMS) flows These are basic tests to make sure that the pages stay stitched together. Added for both the jobs and send SMS flows (because the send SMS flow didn’t have any before)
2015-12-17 16:21:34 +00:00
Redirect the old jobs URL
2020-03-02 13:48:32 +00:00
def test_old_jobs_hub_redirects(
Show jobs in basic view There are some teams who send jobs on a daily/weekly basis. They have team members who only use Notify for this purpose. So they would probably benefit from basic view, because they don’t need to see the dashboard. This commit: - adds a new item (uploaded files) to the basic view navigation for teams that have sent at least one job - makes the job pages visible to basic view users I think we should do this now, rather than as a later enhancement to basic view. We only have one chance to announce the feature, so teams who do send jobs may otherwise discount it as not useful for them and the opportunity to have them use it is lost.
2018-07-30 17:40:32 +01:00
client_request,
update tests to reflect new code also change jobs.py to filter out test jobs (since we dont need to see em) and to use the new statuses filter rather than filtering on front end
2016-10-05 17:45:04 +01:00
):
Redirect the old jobs URL
2020-03-02 13:48:32 +00:00
client_request.get(
'main.view_jobs',
service_id=SERVICE_ONE_ID,
_expected_status=302,
_expected_redirect=url_for(
'main.uploads',
service_id=SERVICE_ONE_ID,
)
)
Show jobs in basic view There are some teams who send jobs on a daily/weekly basis. They have team members who only use Notify for this purpose. So they would probably benefit from basic view, because they don’t need to see the dashboard. This commit: - adds a new item (uploaded files) to the basic view navigation for teams that have sent at least one job - makes the job pages visible to basic view users I think we should do this now, rather than as a later enhancement to basic view. We only have one chance to announce the feature, so teams who do send jobs may otherwise discount it as not useful for them and the opportunity to have them use it is lost.
2018-07-30 17:40:32 +01:00
@pytest.mark.parametrize('user', [
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
create_active_user_with_permissions(),
create_active_caseworking_user(),
Show jobs in basic view There are some teams who send jobs on a daily/weekly basis. They have team members who only use Notify for this purpose. So they would probably benefit from basic view, because they don’t need to see the dashboard. This commit: - adds a new item (uploaded files) to the basic view navigation for teams that have sent at least one job - makes the job pages visible to basic view users I think we should do this now, rather than as a later enhancement to basic view. We only have one chance to announce the feature, so teams who do send jobs may otherwise discount it as not useful for them and the opportunity to have them use it is lost.
2018-07-30 17:40:32 +01:00
])
Make jobs filterable by notification status We can filter all notifications by status already. This commit reuses the same code to filter the notifications for a job by status. This means that, visually we can show the count on a job the same as we do for all notifications, which is similar to how we show the counts on the dashboard, so hopefully it feels like a bit more of a solid thing. This also applies to CSV downloads and AJAX updates, which will inherit any filtering that their parent page has applied.
2016-06-08 16:34:26 +01:00
@pytest.mark.parametrize(
"status_argument, expected_api_call", [
(
'',
Break down usage by month, filter by year The previous, weekly activity breakdown was what we reckoned might be useful. But now that we have people using the platform it feels like aggregating a service’s usage by month is: - matches the timeframe users report on within their organisation - is consistent with the usage page And like the usage page this commit also limits the page to only show one financial year’s worth of data at once (rather than data for all time). This commit also makes some changes to the jobs view code so that our aggregation of failure states is consistent between the dashboard pages and the jobs pages.
2017-01-30 17:27:09 +00:00
[
remove antivirus code (email does not allow attachments via ui)
2022-12-05 16:35:46 -05:00
'created', 'pending', 'sending', 'delivered', 'sent', 'failed',
'temporary-failure', 'permanent-failure', 'technical-failure',
'validation-failed'
Break down usage by month, filter by year The previous, weekly activity breakdown was what we reckoned might be useful. But now that we have people using the platform it feels like aggregating a service’s usage by month is: - matches the timeframe users report on within their organisation - is consistent with the usage page And like the usage page this commit also limits the page to only show one financial year’s worth of data at once (rather than data for all time). This commit also makes some changes to the jobs view code so that our aggregation of failure states is consistent between the dashboard pages and the jobs pages.
2017-01-30 17:27:09 +00:00
]
Make jobs filterable by notification status We can filter all notifications by status already. This commit reuses the same code to filter the notifications for a job by status. This means that, visually we can show the count on a job the same as we do for all notifications, which is similar to how we show the counts on the dashboard, so hopefully it feels like a bit more of a solid thing. This also applies to CSV downloads and AJAX updates, which will inherit any filtering that their parent page has applied.
2016-06-08 16:34:26 +01:00
),
(
'sending',
remove antivirus code (email does not allow attachments via ui)
2022-12-05 16:35:46 -05:00
['sending', 'created', 'pending']
Make jobs filterable by notification status We can filter all notifications by status already. This commit reuses the same code to filter the notifications for a job by status. This means that, visually we can show the count on a job the same as we do for all notifications, which is similar to how we show the counts on the dashboard, so hopefully it feels like a bit more of a solid thing. This also applies to CSV downloads and AJAX updates, which will inherit any filtering that their parent page has applied.
2016-06-08 16:34:26 +01:00
),
(
'delivered',
big commit with letters removal
2022-12-05 15:33:44 -05:00
['delivered', 'sent']
Make jobs filterable by notification status We can filter all notifications by status already. This commit reuses the same code to filter the notifications for a job by status. This means that, visually we can show the count on a job the same as we do for all notifications, which is similar to how we show the counts on the dashboard, so hopefully it feels like a bit more of a solid thing. This also applies to CSV downloads and AJAX updates, which will inherit any filtering that their parent page has applied.
2016-06-08 16:34:26 +01:00
),
(
'failed',
Add validation-failed status to FAILURE_STATUSES in admin utils
2019-01-10 15:54:31 +00:00
[
remove antivirus code (email does not allow attachments via ui)
2022-12-05 16:35:46 -05:00
'failed', 'temporary-failure', 'permanent-failure', 'technical-failure',
Add validation-failed status to FAILURE_STATUSES in admin utils
2019-01-10 15:54:31 +00:00
'validation-failed'
]
Make jobs filterable by notification status We can filter all notifications by status already. This commit reuses the same code to filter the notifications for a job by status. This means that, visually we can show the count on a job the same as we do for all notifications, which is similar to how we show the counts on the dashboard, so hopefully it feels like a bit more of a solid thing. This also applies to CSV downloads and AJAX updates, which will inherit any filtering that their parent page has applied.
2016-06-08 16:34:26 +01:00
)
]
)
more test fixes & letter trimming
2022-11-22 22:50:47 -05:00
@freeze_time("2016-01-01 16:09:00.061258")
Make job page poll for updates This is a first go at having the job page update without refreshing. The approach I’ve taken is to do all the rendering of HTML on the server side, rather than use a Javascipt templating engine like mustache. This ensures that we don’t have to maintain two sets of templates. So the approach is to split the job page into partials. These partials can then: - be included in the job page to render the whole page - be rendered indivudually and then returned as a blob of HTML inside a JSON response Then I’ve added a Javascript module which looks for areas of the page that should be reloaded. For each area of the page it will poll a URL and re-render that section of the page when it gets new HTML. It implements some throttling so that API calls will never happen more frequently than 0.67 times/second.
2016-03-02 17:36:20 +00:00
def test_should_show_page_for_one_job(
Show jobs in basic view There are some teams who send jobs on a daily/weekly basis. They have team members who only use Notify for this purpose. So they would probably benefit from basic view, because they don’t need to see the dashboard. This commit: - adds a new item (uploaded files) to the basic view navigation for teams that have sent at least one job - makes the job pages visible to basic view users I think we should do this now, rather than as a later enhancement to basic view. We only have one chance to announce the feature, so teams who do send jobs may otherwise discount it as not useful for them and the opportunity to have them use it is lost.
2018-07-30 17:40:32 +01:00
client_request,
Make job page poll for updates This is a first go at having the job page update without refreshing. The approach I’ve taken is to do all the rendering of HTML on the server side, rather than use a Javascipt templating engine like mustache. This ensures that we don’t have to maintain two sets of templates. So the approach is to split the job page into partials. These partials can then: - be included in the job page to render the whole page - be rendered indivudually and then returned as a blob of HTML inside a JSON response Then I’ve added a Javascript module which looks for areas of the page that should be reloaded. For each area of the page it will poll a URL and re-render that section of the page when it gets new HTML. It implements some throttling so that API calls will never happen more frequently than 0.67 times/second.
2016-03-02 17:36:20 +00:00
mock_get_service_template,
Fixed download bug for services with api notifications. Re-organised the mock job and job_json methods.
2016-05-24 12:34:29 +01:00
mock_get_job,
Update the jobs and activity page to show the user that created the job.
2016-05-11 11:57:31 +01:00
mocker,
Fixed download bug for services with api notifications. Re-organised the mock job and job_json methods.
2016-05-24 12:34:29 +01:00
mock_get_notifications,
Cache service data retention in Redis Adds caching for service data retention. This removes separate API client methods to retrieve individual data retention records by id or type in favor of a single method that fetches and caches all retention settings configured for the service. This makes it much easier to invalidate cache when settings change. Lookup by id or type is provided by helper methods in the service model.
2018-12-03 17:19:38 +00:00
mock_get_service_data_retention,
Make jobs filterable by notification status We can filter all notifications by status already. This commit reuses the same code to filter the notifications for a job by status. This means that, visually we can show the count on a job the same as we do for all notifications, which is similar to how we show the counts on the dashboard, so hopefully it feels like a bit more of a solid thing. This also applies to CSV downloads and AJAX updates, which will inherit any filtering that their parent page has applied.
2016-06-08 16:34:26 +01:00
fake_uuid,
status_argument,
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
expected_api_call,
Show jobs in basic view There are some teams who send jobs on a daily/weekly basis. They have team members who only use Notify for this purpose. So they would probably benefit from basic view, because they don’t need to see the dashboard. This commit: - adds a new item (uploaded files) to the basic view navigation for teams that have sent at least one job - makes the job pages visible to basic view users I think we should do this now, rather than as a later enhancement to basic view. We only have one chance to announce the feature, so teams who do send jobs may otherwise discount it as not useful for them and the opportunity to have them use it is lost.
2018-07-30 17:40:32 +01:00
user,
Make job page poll for updates This is a first go at having the job page update without refreshing. The approach I’ve taken is to do all the rendering of HTML on the server side, rather than use a Javascipt templating engine like mustache. This ensures that we don’t have to maintain two sets of templates. So the approach is to split the job page into partials. These partials can then: - be included in the job page to render the whole page - be rendered indivudually and then returned as a blob of HTML inside a JSON response Then I’ve added a Javascript module which looks for areas of the page that should be reloaded. For each area of the page it will poll a URL and re-render that section of the page when it gets new HTML. It implements some throttling so that API calls will never happen more frequently than 0.67 times/second.
2016-03-02 17:36:20 +00:00
):
Revert "Merge pull request #1336 from alphagov/revert-show-notifications" This reverts commit 7e354ff341172041d6141b50833af6262308fcb4, reversing changes made to 6f3bcff32fbfc78b4df0558d08605a260786112f.
2017-06-24 17:12:45 +01:00
Show jobs in basic view There are some teams who send jobs on a daily/weekly basis. They have team members who only use Notify for this purpose. So they would probably benefit from basic view, because they don’t need to see the dashboard. This commit: - adds a new item (uploaded files) to the basic view navigation for teams that have sent at least one job - makes the job pages visible to basic view users I think we should do this now, rather than as a later enhancement to basic view. We only have one chance to announce the feature, so teams who do send jobs may otherwise discount it as not useful for them and the opportunity to have them use it is lost.
2018-07-30 17:40:32 +01:00
page = client_request.get(
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
'main.view_job',
Show jobs in basic view There are some teams who send jobs on a daily/weekly basis. They have team members who only use Notify for this purpose. So they would probably benefit from basic view, because they don’t need to see the dashboard. This commit: - adds a new item (uploaded files) to the basic view navigation for teams that have sent at least one job - makes the job pages visible to basic view users I think we should do this now, rather than as a later enhancement to basic view. We only have one chance to announce the feature, so teams who do send jobs may otherwise discount it as not useful for them and the opportunity to have them use it is lost.
2018-07-30 17:40:32 +01:00
service_id=SERVICE_ONE_ID,
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
job_id=fake_uuid,
status=status_argument
Show jobs in basic view There are some teams who send jobs on a daily/weekly basis. They have team members who only use Notify for this purpose. So they would probably benefit from basic view, because they don’t need to see the dashboard. This commit: - adds a new item (uploaded files) to the basic view navigation for teams that have sent at least one job - makes the job pages visible to basic view users I think we should do this now, rather than as a later enhancement to basic view. We only have one chance to announce the feature, so teams who do send jobs may otherwise discount it as not useful for them and the opportunity to have them use it is lost.
2018-07-30 17:40: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 page.h1.text.strip() == 'thisisatest.csv'
assert ' '.join(page.find('tbody').find('tr').text.split()) == (
Replace UK phone numbers in tests with US numbers
2022-12-22 22:11:07 -05:00
'2021234567 template content Delivered 1 January at 11:10am'
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
)
assert page.find('div', {'data-key': 'notifications'})['data-resource'] == url_for(
'main.view_job_updates',
Show jobs in basic view There are some teams who send jobs on a daily/weekly basis. They have team members who only use Notify for this purpose. So they would probably benefit from basic view, because they don’t need to see the dashboard. This commit: - adds a new item (uploaded files) to the basic view navigation for teams that have sent at least one job - makes the job pages visible to basic view users I think we should do this now, rather than as a later enhancement to basic view. We only have one chance to announce the feature, so teams who do send jobs may otherwise discount it as not useful for them and the opportunity to have them use it is lost.
2018-07-30 17:40:32 +01:00
service_id=SERVICE_ONE_ID,
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
job_id=fake_uuid,
status=status_argument,
)
Remove value of download attribute on links We should standardise on <a download> rather than <a download="download"> everywhere. The value of the download attribute tells the browser what filename to use, but is overridden by the Content-Disposition HTTP header. Since it’s not being used, we should remove it for the sake of disambiguation.
2018-01-02 14:38:14 +00:00
csv_link = page.select_one('a[download]')
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert csv_link['href'] == url_for(
'main.view_job_csv',
Show jobs in basic view There are some teams who send jobs on a daily/weekly basis. They have team members who only use Notify for this purpose. So they would probably benefit from basic view, because they don’t need to see the dashboard. This commit: - adds a new item (uploaded files) to the basic view navigation for teams that have sent at least one job - makes the job pages visible to basic view users I think we should do this now, rather than as a later enhancement to basic view. We only have one chance to announce the feature, so teams who do send jobs may otherwise discount it as not useful for them and the opportunity to have them use it is lost.
2018-07-30 17:40:32 +01:00
service_id=SERVICE_ONE_ID,
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
job_id=fake_uuid,
status=status_argument
)
Add filetype to all links to download user reports / examples
2022-05-19 12:06:43 +01:00
assert csv_link.text == 'Download this report (CSV)'
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert page.find('span', {'id': 'time-left'}).text == 'Data available for 7 days'
Always go back to previous page from notification When looking at a notification you can either be coming from the page of all notifications, or from a job. Currently the back link always takes you to the page of all notifications. This commit makes it a bit more sophisticated so if you’ve come from looking at a job, you go back to the job.
2019-05-09 17:33:22 +01:00
assert normalize_spaces(page.select_one('tbody tr').text) == normalize_spaces(
Replace UK phone numbers in tests with US numbers
2022-12-22 22:11:07 -05:00
'2021234567 '
Always go back to previous page from notification When looking at a notification you can either be coming from the page of all notifications, or from a job. Currently the back link always takes you to the page of all notifications. This commit makes it a bit more sophisticated so if you’ve come from looking at a job, you go back to the job.
2019-05-09 17:33:22 +01:00
'template content '
'Delivered 1 January at 11:10am'
)
assert page.select_one('tbody tr a')['href'] == url_for(
'main.view_notification',
service_id=SERVICE_ONE_ID,
notification_id=sample_uuid(),
from_job=fake_uuid,
)
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
mock_get_notifications.assert_called_with(
Show jobs in basic view There are some teams who send jobs on a daily/weekly basis. They have team members who only use Notify for this purpose. So they would probably benefit from basic view, because they don’t need to see the dashboard. This commit: - adds a new item (uploaded files) to the basic view navigation for teams that have sent at least one job - makes the job pages visible to basic view users I think we should do this now, rather than as a later enhancement to basic view. We only have one chance to announce the feature, so teams who do send jobs may otherwise discount it as not useful for them and the opportunity to have them use it is lost.
2018-07-30 17:40:32 +01:00
SERVICE_ONE_ID,
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
fake_uuid,
status=expected_api_call
make sure static subdir 404s correctly before each request, we put the current service on the flask session, except for with the static folder, cos it's not needed.... except, if we 404, then we return the 404 template, which checks if you're logged in or not to display different nav bar items. This was crashing when current_service wasn't set, so we now set it. also cleaned up some imports and stuff in test files
2017-05-04 11:28:45 +01:00
)
Make job page poll for updates This is a first go at having the job page update without refreshing. The approach I’ve taken is to do all the rendering of HTML on the server side, rather than use a Javascipt templating engine like mustache. This ensures that we don’t have to maintain two sets of templates. So the approach is to split the job page into partials. These partials can then: - be included in the job page to render the whole page - be rendered indivudually and then returned as a blob of HTML inside a JSON response Then I’ve added a Javascript module which looks for areas of the page that should be reloaded. For each area of the page it will poll a URL and re-render that section of the page when it gets new HTML. It implements some throttling so that API calls will never happen more frequently than 0.67 times/second.
2016-03-02 17:36:20 +00:00
Test Data available message for jobs with flexible data retention
2018-11-26 15:28:09 +00:00
@freeze_time("2016-01-01 11:09:00.061258")
def test_should_show_page_for_one_job_with_flexible_data_retention(
client_request,
active_user_with_permissions,
mock_get_service_template,
mock_get_job,
mocker,
mock_get_notifications,
Cache service data retention in Redis Adds caching for service data retention. This removes separate API client methods to retrieve individual data retention records by id or type in favor of a single method that fetches and caches all retention settings configured for the service. This makes it much easier to invalidate cache when settings change. Lookup by id or type is provided by helper methods in the service model.
2018-12-03 17:19:38 +00:00
mock_get_service_data_retention,
Test Data available message for jobs with flexible data retention
2018-11-26 15:28:09 +00:00
fake_uuid,
):
Cache service data retention in Redis Adds caching for service data retention. This removes separate API client methods to retrieve individual data retention records by id or type in favor of a single method that fetches and caches all retention settings configured for the service. This makes it much easier to invalidate cache when settings change. Lookup by id or type is provided by helper methods in the service model.
2018-12-03 17:19:38 +00:00
mock_get_service_data_retention.side_effect = [[{"days_of_retention": 10, "notification_type": "sms"}]]
Test Data available message for jobs with flexible data retention
2018-11-26 15:28:09 +00:00
page = client_request.get(
'main.view_job',
service_id=SERVICE_ONE_ID,
job_id=fake_uuid,
status='delivered'
)
assert page.find('span', {'id': 'time-left'}).text == 'Data available for 10 days'
Can't cancel letter job if job not processed yet Also add more tests for showing or not the cancel those letters link Also check if all notifications already in database Upgrade delete button text logic to handle more cases Also corrections following review
2019-06-24 17:57:04 +01:00
assert "Cancel sending these letters" not in page
Test Data available message for jobs with flexible data retention
2018-11-26 15:28:09 +00:00
Fairly large refactor of tests related to getting/viewing notifications
2017-01-13 11:37:14 +00:00
def test_get_jobs_should_tell_user_if_more_than_one_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,
Fairly large refactor of tests related to getting/viewing notifications
2017-01-13 11:37:14 +00:00
fake_uuid,
service_one,
mock_get_job,
mock_get_service_template,
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_notifications_with_previous_next,
Cache service data retention in Redis Adds caching for service data retention. This removes separate API client methods to retrieve individual data retention records by id or type in favor of a single method that fetches and caches all retention settings configured for the service. This makes it much easier to invalidate cache when settings change. Lookup by id or type is provided by helper methods in the service model.
2018-12-03 17:19:38 +00:00
mock_get_service_data_retention,
Fairly large refactor of tests related to getting/viewing notifications
2017-01-13 11:37:14 +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(
Fairly large refactor of tests related to getting/viewing notifications
2017-01-13 11:37:14 +00:00
'main.view_job',
service_id=service_one['id'],
job_id=fake_uuid,
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
status='',
)
Fairly large refactor of tests related to getting/viewing notifications
2017-01-13 11:37:14 +00:00
assert page.find('p', {'class': 'table-show-more-link'}).text.strip() == 'Only showing the first 50 rows'
Don’t show the download until the job is complete The CSV report isn’t very useful until it has all the rows from your original file. So we shouldn’t show you the link until all notifications have been created. Until this point, it’s useful to know how much longer you need to wait, so this commit adds a percentage count of how much of the file has been processed.
2016-08-02 21:27:23 +01:00
def test_should_show_job_in_progress(
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,
Don’t show the download until the job is complete The CSV report isn’t very useful until it has all the rows from your original file. So we shouldn’t show you the link until all notifications have been created. Until this point, it’s useful to know how much longer you need to wait, so this commit adds a percentage count of how much of the file has been processed.
2016-08-02 21:27:23 +01:00
service_one,
active_user_with_permissions,
mock_get_service_template,
mock_get_job_in_progress,
mocker,
mock_get_notifications,
Cache service data retention in Redis Adds caching for service data retention. This removes separate API client methods to retrieve individual data retention records by id or type in favor of a single method that fetches and caches all retention settings configured for the service. This makes it much easier to invalidate cache when settings change. Lookup by id or type is provided by helper methods in the service model.
2018-12-03 17:19:38 +00:00
mock_get_service_data_retention,
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
fake_uuid,
Don’t show the download until the job is complete The CSV report isn’t very useful until it has all the rows from your original file. So we shouldn’t show you the link until all notifications have been created. Until this point, it’s useful to know how much longer you need to wait, so this commit adds a percentage count of how much of the file has been processed.
2016-08-02 21:27:23 +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(
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
'main.view_job',
service_id=service_one['id'],
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
job_id=fake_uuid,
)
Don’t show blue boxes once notifications have gone You can click the blue boxes to filter the list of notifications. Once the notifications have gone there’s nothing to filter, so we should just show the numbers but without them being clickable.
2019-12-30 16:53:45 +00:00
assert [
normalize_spaces(link.text)
Fix unit tests for changes to the pill component.
2020-09-04 14:32:07 +01:00
for link in page.select('.pill a:not(.pill-item--selected)')
Don’t show blue boxes once notifications have gone You can click the blue boxes to filter the list of notifications. Once the notifications have gone there’s nothing to filter, so we should just show the numbers but without them being clickable.
2019-12-30 16:53:45 +00:00
] == [
Add hidden text for pills on job page The links in the blue boxes on the job page needed hidden text so that they work out of context. This changes the text from "10 sending" to "10 sending text messages" (with the message type hidden text).
2021-02-24 14:34:56 +00:00
'10 sending text messages', '0 delivered text messages', '0 failed text messages'
Don’t show blue boxes once notifications have gone You can click the blue boxes to filter the list of notifications. Once the notifications have gone there’s nothing to filter, so we should just show the numbers but without them being clickable.
2019-12-30 16:53:45 +00:00
]
Add a test for the no notifications message This wasn’t tested before.
2020-01-03 14:14:38 +00:00
assert page.select_one('p.hint').text.strip() == 'Report is 50% complete…'
def test_should_show_job_without_notifications(
client_request,
service_one,
active_user_with_permissions,
mock_get_service_template,
mock_get_job_in_progress,
mocker,
mock_get_notifications_with_no_notifications,
mock_get_service_data_retention,
fake_uuid,
):
page = client_request.get(
'main.view_job',
service_id=service_one['id'],
job_id=fake_uuid,
)
Don’t show blue boxes once notifications have gone You can click the blue boxes to filter the list of notifications. Once the notifications have gone there’s nothing to filter, so we should just show the numbers but without them being clickable.
2019-12-30 16:53:45 +00:00
assert [
normalize_spaces(link.text)
Fix unit tests for changes to the pill component.
2020-09-04 14:32:07 +01:00
for link in page.select('.pill a:not(.pill-item--selected)')
Don’t show blue boxes once notifications have gone You can click the blue boxes to filter the list of notifications. Once the notifications have gone there’s nothing to filter, so we should just show the numbers but without them being clickable.
2019-12-30 16:53:45 +00:00
] == [
Add hidden text for pills on job page The links in the blue boxes on the job page needed hidden text so that they work out of context. This changes the text from "10 sending" to "10 sending text messages" (with the message type hidden text).
2021-02-24 14:34:56 +00:00
'10 sending text messages', '0 delivered text messages', '0 failed text messages'
Don’t show blue boxes once notifications have gone You can click the blue boxes to filter the list of notifications. Once the notifications have gone there’s nothing to filter, so we should just show the numbers but without them being clickable.
2019-12-30 16:53:45 +00:00
]
Add a test for the no notifications message This wasn’t tested before.
2020-01-03 14:14:38 +00:00
assert page.select_one('p.hint').text.strip() == 'Report is 50% complete…'
Add a more accurate missing notifications message Notifications could be missing because: - none have been created yet - they’ve been deleted This commit adds separate error messages for each case, rather than a less helpful generic one.
2019-12-30 16:37:50 +00:00
assert page.select_one('tbody').text.strip() == 'No messages to show yet…'
Don’t show the download until the job is complete The CSV report isn’t very useful until it has all the rows from your original file. So we shouldn’t show you the link until all notifications have been created. Until this point, it’s useful to know how much longer you need to wait, so this commit adds a percentage count of how much of the file has been processed.
2016-08-02 21:27:23 +01:00
Show status when job has exceeded the daily sending limit If a job exceeds the daily sending limit, show that on the job page. The job is only created if the sending limit has been reached when the delivery app is processing the job, usually this error is caught at the time the CSV is uploaded and the job is not created.
2021-07-05 14:13:20 +01:00
def test_should_show_job_with_sending_limit_exceeded_status(
client_request,
service_one,
active_user_with_permissions,
mock_get_service_template,
mock_get_job_with_sending_limits_exceeded,
mock_get_notifications_with_no_notifications,
mock_get_service_data_retention,
fake_uuid,
):
page = client_request.get(
'main.view_job',
service_id=service_one['id'],
job_id=fake_uuid,
)
Update content
2021-07-14 09:54:28 +01:00
Show status when job has exceeded the daily sending limit If a job exceeds the daily sending limit, show that on the job page. The job is only created if the sending limit has been reached when the delivery app is processing the job, usually this error is caught at the time the CSV is uploaded and the job is not created.
2021-07-05 14:13:20 +01:00
assert normalize_spaces(page.select('main p')[1].text) == (
2767 passing
2022-08-05 00:25:03 -07:00
"Notify cannot send these messages because you have reached your daily limit. You can only send 1,000 messages per day." # noqa
Update content
2021-07-14 09:54:28 +01:00
)
assert normalize_spaces(page.select('main p')[2].text) == (
us → u.s.
2022-12-06 11:03:47 -05:00
"Upload this spreadsheet again tomorrow or contact the U.S. Notify team to raise the limit."
Show status when job has exceeded the daily sending limit If a job exceeds the daily sending limit, show that on the job page. The job is only created if the sending limit has been reached when the delivery app is processing the job, usually this error is caught at the time the CSV is uploaded and the job is not created.
2021-07-05 14:13:20 +01:00
)
Don’t mock job processing in the future It could hide bugs or make the tests harder to understand later on if what they’re testing is an impossible scenario.
2020-01-21 14:09:54 +00:00
@freeze_time("2020-01-10 1:0:0")
Use time to determine why notifications don’t exist Notifications won’t exist for a job if: - it’s just started - it started a long time ago (older than the retention period) We have a bug where: 1. Job starts processing, puts notifications on queue 2. Job finishes processing, sets status to `finished` 3. First notification gets picked up off the queue and put in the database In between 2. and 3. it’s possible for a job to be finished, but also to have no notifications. We’re saying this is because the notifications have been deleted, whereas really it’s because they haven’t been created yet. This commit fixes that bug by introducing the concept of recency for jobs. ‘Recent’ is defined as 1 day, which is: - a lot longer than it takes to create any notifications - a bit shorter than anyone’s retention time N.B. `processing_started` is defined here: https://github.com/alphagov/notifications-api/blob/879ba1d5f092dbf6e15bf9adadd53e4657660490/app/models.py#L1194 It can be `None` for scheduled jobs that haven’t started yet.
2020-01-16 16:58:26 +00:00
@pytest.mark.parametrize('created_at, processing_started, expected_message', (
# Recently created, not yet started
(datetime(2020, 1, 10, 0, 0, 0), None, (
'No messages to show yet…'
)),
# Just started
(datetime(2020, 1, 10, 0, 0, 0), datetime(2020, 1, 10, 0, 0, 1), (
fix skips and xfails
2023-05-26 12:35:48 -07:00
'No messages to show yet…'
Use time to determine why notifications don’t exist Notifications won’t exist for a job if: - it’s just started - it started a long time ago (older than the retention period) We have a bug where: 1. Job starts processing, puts notifications on queue 2. Job finishes processing, sets status to `finished` 3. First notification gets picked up off the queue and put in the database In between 2. and 3. it’s possible for a job to be finished, but also to have no notifications. We’re saying this is because the notifications have been deleted, whereas really it’s because they haven’t been created yet. This commit fixes that bug by introducing the concept of recency for jobs. ‘Recent’ is defined as 1 day, which is: - a lot longer than it takes to create any notifications - a bit shorter than anyone’s retention time N.B. `processing_started` is defined here: https://github.com/alphagov/notifications-api/blob/879ba1d5f092dbf6e15bf9adadd53e4657660490/app/models.py#L1194 It can be `None` for scheduled jobs that haven’t started yet.
2020-01-16 16:58:26 +00:00
)),
# Created a while ago, just started
(datetime(2020, 1, 1, 0, 0, 0), datetime(2020, 1, 10, 0, 0, 1), (
fix skips and xfails
2023-05-26 12:35:48 -07:00
'No messages to show yet…'
Use time to determine why notifications don’t exist Notifications won’t exist for a job if: - it’s just started - it started a long time ago (older than the retention period) We have a bug where: 1. Job starts processing, puts notifications on queue 2. Job finishes processing, sets status to `finished` 3. First notification gets picked up off the queue and put in the database In between 2. and 3. it’s possible for a job to be finished, but also to have no notifications. We’re saying this is because the notifications have been deleted, whereas really it’s because they haven’t been created yet. This commit fixes that bug by introducing the concept of recency for jobs. ‘Recent’ is defined as 1 day, which is: - a lot longer than it takes to create any notifications - a bit shorter than anyone’s retention time N.B. `processing_started` is defined here: https://github.com/alphagov/notifications-api/blob/879ba1d5f092dbf6e15bf9adadd53e4657660490/app/models.py#L1194 It can be `None` for scheduled jobs that haven’t started yet.
2020-01-16 16:58:26 +00:00
)),
Test the boundary conditions Since date math can be hard it’s good to test as close to the boundary as possible, which hopefully catches stuff like timezone related bugs.
2020-01-21 14:15:48 +00:00
# Created a while ago, started just within the last 24h
fix skips and xfails
2023-05-26 12:35:48 -07:00
# TODO -- should pass, tech debt due to timezone changes, re-evaluate after UTC changes
pytest.param(
datetime(2020, 1, 1, 0, 0, 0),
datetime(2020, 1, 9, 6, 0, 1),
('No messages to show yet…'),
marks=pytest.mark.xfail(raises=AssertionError),
),
Test the boundary conditions Since date math can be hard it’s good to test as close to the boundary as possible, which hopefully catches stuff like timezone related bugs.
2020-01-21 14:15:48 +00:00
# Created a while ago, started exactly 24h ago
Add comment clarifying timings in test case
2020-01-23 16:31:21 +00:00
# ---
# It doesn’t matter that 24h (1 day) and 7 days (the service’s data
# retention) don’t match up. We’re testing the case of no
# notifications existing more than 1 day after the job started
# processing. In this case we assume it’s because the service’s
# data retention has kicked in.
Test the boundary conditions Since date math can be hard it’s good to test as close to the boundary as possible, which hopefully catches stuff like timezone related bugs.
2020-01-21 14:15:48 +00:00
(datetime(2020, 1, 1, 0, 0, 0), datetime(2020, 1, 9, 1, 0, 0), (
Use time to determine why notifications don’t exist Notifications won’t exist for a job if: - it’s just started - it started a long time ago (older than the retention period) We have a bug where: 1. Job starts processing, puts notifications on queue 2. Job finishes processing, sets status to `finished` 3. First notification gets picked up off the queue and put in the database In between 2. and 3. it’s possible for a job to be finished, but also to have no notifications. We’re saying this is because the notifications have been deleted, whereas really it’s because they haven’t been created yet. This commit fixes that bug by introducing the concept of recency for jobs. ‘Recent’ is defined as 1 day, which is: - a lot longer than it takes to create any notifications - a bit shorter than anyone’s retention time N.B. `processing_started` is defined here: https://github.com/alphagov/notifications-api/blob/879ba1d5f092dbf6e15bf9adadd53e4657660490/app/models.py#L1194 It can be `None` for scheduled jobs that haven’t started yet.
2020-01-16 16:58:26 +00:00
'These messages have been deleted because they were sent more than 7 days ago'
)),
))
Don’t show progress once notifications are gone We work out how complete a job’s processing is by looking at how many notifications have been created. Later, we deleted all the notifications, according to the data retention schedule. This makes it look like the job has gone back to 0% processed. This commit accounts for this by not showing the % complete message once a finished job has had its notifications deleted.
2019-12-30 16:25:09 +00:00
def test_should_show_old_job(
client_request,
service_one,
active_user_with_permissions,
mock_get_service_template,
mocker,
mock_get_notifications_with_no_notifications,
mock_get_service_data_retention,
fake_uuid,
Use time to determine why notifications don’t exist Notifications won’t exist for a job if: - it’s just started - it started a long time ago (older than the retention period) We have a bug where: 1. Job starts processing, puts notifications on queue 2. Job finishes processing, sets status to `finished` 3. First notification gets picked up off the queue and put in the database In between 2. and 3. it’s possible for a job to be finished, but also to have no notifications. We’re saying this is because the notifications have been deleted, whereas really it’s because they haven’t been created yet. This commit fixes that bug by introducing the concept of recency for jobs. ‘Recent’ is defined as 1 day, which is: - a lot longer than it takes to create any notifications - a bit shorter than anyone’s retention time N.B. `processing_started` is defined here: https://github.com/alphagov/notifications-api/blob/879ba1d5f092dbf6e15bf9adadd53e4657660490/app/models.py#L1194 It can be `None` for scheduled jobs that haven’t started yet.
2020-01-16 16:58:26 +00:00
created_at,
processing_started,
expected_message,
Don’t show progress once notifications are gone We work out how complete a job’s processing is by looking at how many notifications have been created. Later, we deleted all the notifications, according to the data retention schedule. This makes it look like the job has gone back to 0% processed. This commit accounts for this by not showing the % complete message once a finished job has had its notifications deleted.
2019-12-30 16:25:09 +00:00
):
Use time to determine why notifications don’t exist Notifications won’t exist for a job if: - it’s just started - it started a long time ago (older than the retention period) We have a bug where: 1. Job starts processing, puts notifications on queue 2. Job finishes processing, sets status to `finished` 3. First notification gets picked up off the queue and put in the database In between 2. and 3. it’s possible for a job to be finished, but also to have no notifications. We’re saying this is because the notifications have been deleted, whereas really it’s because they haven’t been created yet. This commit fixes that bug by introducing the concept of recency for jobs. ‘Recent’ is defined as 1 day, which is: - a lot longer than it takes to create any notifications - a bit shorter than anyone’s retention time N.B. `processing_started` is defined here: https://github.com/alphagov/notifications-api/blob/879ba1d5f092dbf6e15bf9adadd53e4657660490/app/models.py#L1194 It can be `None` for scheduled jobs that haven’t started yet.
2020-01-16 16:58:26 +00:00
mocker.patch('app.job_api_client.get_job', return_value={
"data": job_json(
SERVICE_ONE_ID,
active_user_with_permissions,
created_at=created_at.replace(tzinfo=timezone.utc).isoformat(),
processing_started=(
processing_started.replace(tzinfo=timezone.utc).isoformat()
if processing_started else None
),
),
})
Don’t show progress once notifications are gone We work out how complete a job’s processing is by looking at how many notifications have been created. Later, we deleted all the notifications, according to the data retention schedule. This makes it look like the job has gone back to 0% processed. This commit accounts for this by not showing the % complete message once a finished job has had its notifications deleted.
2019-12-30 16:25:09 +00:00
page = client_request.get(
'main.view_job',
Use time to determine why notifications don’t exist Notifications won’t exist for a job if: - it’s just started - it started a long time ago (older than the retention period) We have a bug where: 1. Job starts processing, puts notifications on queue 2. Job finishes processing, sets status to `finished` 3. First notification gets picked up off the queue and put in the database In between 2. and 3. it’s possible for a job to be finished, but also to have no notifications. We’re saying this is because the notifications have been deleted, whereas really it’s because they haven’t been created yet. This commit fixes that bug by introducing the concept of recency for jobs. ‘Recent’ is defined as 1 day, which is: - a lot longer than it takes to create any notifications - a bit shorter than anyone’s retention time N.B. `processing_started` is defined here: https://github.com/alphagov/notifications-api/blob/879ba1d5f092dbf6e15bf9adadd53e4657660490/app/models.py#L1194 It can be `None` for scheduled jobs that haven’t started yet.
2020-01-16 16:58:26 +00:00
service_id=SERVICE_ONE_ID,
Don’t show progress once notifications are gone We work out how complete a job’s processing is by looking at how many notifications have been created. Later, we deleted all the notifications, according to the data retention schedule. This makes it look like the job has gone back to 0% processed. This commit accounts for this by not showing the % complete message once a finished job has had its notifications deleted.
2019-12-30 16:25:09 +00:00
job_id=fake_uuid,
)
Fix unit tests for changes to the pill component.
2020-09-04 14:32:07 +01:00
assert not page.select('.pill')
Don’t show progress once notifications are gone We work out how complete a job’s processing is by looking at how many notifications have been created. Later, we deleted all the notifications, according to the data retention schedule. This makes it look like the job has gone back to 0% processed. This commit accounts for this by not showing the % complete message once a finished job has had its notifications deleted.
2019-12-30 16:25:09 +00:00
assert not page.select('p.hint')
assert not page.select('a[download]')
Use time to determine why notifications don’t exist Notifications won’t exist for a job if: - it’s just started - it started a long time ago (older than the retention period) We have a bug where: 1. Job starts processing, puts notifications on queue 2. Job finishes processing, sets status to `finished` 3. First notification gets picked up off the queue and put in the database In between 2. and 3. it’s possible for a job to be finished, but also to have no notifications. We’re saying this is because the notifications have been deleted, whereas really it’s because they haven’t been created yet. This commit fixes that bug by introducing the concept of recency for jobs. ‘Recent’ is defined as 1 day, which is: - a lot longer than it takes to create any notifications - a bit shorter than anyone’s retention time N.B. `processing_started` is defined here: https://github.com/alphagov/notifications-api/blob/879ba1d5f092dbf6e15bf9adadd53e4657660490/app/models.py#L1194 It can be `None` for scheduled jobs that haven’t started yet.
2020-01-16 16:58:26 +00:00
assert page.select_one('tbody').text.strip() == expected_message
Fix HTML showing on old job page Using the `Markup` class tells Jinja that the content is safe to render without any escaping.
2021-06-03 09:39:31 +01:00
assert [
normalize_spaces(column.text)
for column in page.select('main .govuk-grid-column-one-quarter')
] == [
'1 total text messages',
'1 sending text message',
'0 delivered text messages',
'0 failed text messages',
]
Don’t show the download until the job is complete The CSV report isn’t very useful until it has all the rows from your original file. So we shouldn’t show you the link until all notifications have been created. Until this point, it’s useful to know how much longer you need to wait, so this commit adds a percentage count of how much of the file has been processed.
2016-08-02 21:27:23 +01:00
more test fixes & letter trimming
2022-11-22 22:50:47 -05:00
@freeze_time("2016-01-01T05:00:00.061258")
Show message on job page if job is scheduled If a job is scheduled then we can’t show the notifications yet, and the progress report will stay at 0%. In their place we should show what time a job will start. Later on (when the API is ready) this area of the page should also show a cancel button.
2016-08-25 16:49:31 +01:00
def test_should_show_scheduled_job(
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,
Show message on job page if job is scheduled If a job is scheduled then we can’t show the notifications yet, and the progress report will stay at 0%. In their place we should show what time a job will start. Later on (when the API is ready) this area of the page should also show a cancel button.
2016-08-25 16:49:31 +01:00
mock_get_service_template,
mock_get_scheduled_job,
Cache service data retention in Redis Adds caching for service data retention. This removes separate API client methods to retrieve individual data retention records by id or type in favor of a single method that fetches and caches all retention settings configured for the service. This makes it much easier to invalidate cache when settings change. Lookup by id or type is provided by helper methods in the service model.
2018-12-03 17:19:38 +00:00
mock_get_service_data_retention,
Show message on job page if job is scheduled If a job is scheduled then we can’t show the notifications yet, and the progress report will stay at 0%. In their place we should show what time a job will start. Later on (when the API is ready) this area of the page should also show a cancel button.
2016-08-25 16:49:31 +01:00
mock_get_notifications,
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
fake_uuid,
Show message on job page if job is scheduled If a job is scheduled then we can’t show the notifications yet, and the progress report will stay at 0%. In their place we should show what time a job will start. Later on (when the API is ready) this area of the page should also show a cancel button.
2016-08-25 16:49:31 +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(
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
'main.view_job',
Revert "Merge pull request #1336 from alphagov/revert-show-notifications" This reverts commit 7e354ff341172041d6141b50833af6262308fcb4, reversing changes made to 6f3bcff32fbfc78b4df0558d08605a260786112f.
2017-06-24 17:12:45 +01:00
service_id=SERVICE_ONE_ID,
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
job_id=fake_uuid,
)
Show message on job page if job is scheduled If a job is scheduled then we can’t show the notifications yet, and the progress report will stay at 0%. In their place we should show what time a job will start. Later on (when the API is ready) this area of the page should also show a cancel button.
2016-08-25 16:49:31 +01:00
Revert "Merge pull request #1336 from alphagov/revert-show-notifications" This reverts commit 7e354ff341172041d6141b50833af6262308fcb4, reversing changes made to 6f3bcff32fbfc78b4df0558d08605a260786112f.
2017-06-24 17:12:45 +01:00
assert normalize_spaces(page.select('main p')[1].text) == (
'Sending Two week reminder today at midnight'
)
assert page.select('main p a')[0]['href'] == url_for(
'main.view_template_version',
service_id=SERVICE_ONE_ID,
template_id='5d729fbd-239c-44ab-b498-75a985f3198f',
version=1,
)
Fix python tests broken by cookie banner
2019-12-20 13:51:15 +00:00
assert page.select_one('main button[type=submit]').text.strip() == 'Cancel sending'
Add a cancel job button If you schedule a job you might change your mind or circumstances might change. So you need to be able to cancel it. This commit adds a button on the job page which hits the `…/cancel` API endpoint for a job.
2016-09-01 15:40:49 +01:00
def test_should_cancel_job(
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,
Add a cancel job button If you schedule a job you might change your mind or circumstances might change. So you need to be able to cancel it. This commit adds a button on the job page which hits the `…/cancel` API endpoint for a job.
2016-09-01 15:40:49 +01:00
fake_uuid,
Make a job model for individual jobs This follows the pattern of what we’ve done with services, users and events. It gives us a better interface to the data we get back from the API than dealing with the raw JSON directly. Now is a good time to do this because we’re going to be making a bunch of changes to the jobs pages, and those changes will be easier to code and understand with a sesnsible model behind them.
2020-01-08 12:23:09 +00:00
mock_get_job,
mock_get_service_template,
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
mocker,
Add a cancel job button If you schedule a job you might change your mind or circumstances might change. So you need to be able to cancel it. This commit adds a button on the job page which hits the `…/cancel` API endpoint for a job.
2016-09-01 15:40:49 +01:00
):
Use a ModelList for lists of jobs This follows the pattern of what we’ve done with services, users and events. It gives us a way of neatly instantiating a model for each item in the list we get back from the API and reduces the complexity of the view layer code. Now is a good time to do this because we’re going to be making a bunch of changes to the jobs pages, and those changes will be easier to code and understand with a sensible model behind them.
2020-01-08 14:29:56 +00:00
mock_cancel = mocker.patch('app.job_api_client.cancel_job')
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(
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
'main.cancel_job',
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
service_id=SERVICE_ONE_ID,
job_id=fake_uuid,
_expected_status=302,
_expected_redirect=url_for(
'main.service_dashboard',
service_id=SERVICE_ONE_ID,
)
)
Add a cancel job button If you schedule a job you might change your mind or circumstances might change. So you need to be able to cancel it. This commit adds a button on the job page which hits the `…/cancel` API endpoint for a job.
2016-09-01 15:40:49 +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
mock_cancel.assert_called_once_with(SERVICE_ONE_ID, fake_uuid)
Show message on job page if job is scheduled If a job is scheduled then we can’t show the notifications yet, and the progress report will stay at 0%. In their place we should show what time a job will start. Later on (when the API is ready) this area of the page should also show a cancel button.
2016-08-25 16:49:31 +01:00
Don’t show cancelled jobs anywhere The information about a job doesn’t make sense if a job is cancelled. We could change the information to reflect that the job won’t be sent/ wasn’t sent/was cancelled, but there’s nothing you can really do with this info. So instead let’s: - hide cancelled jobs from the dashboard - hide cancelled jobs from the jobs page - 404 the page if the user tries to click back enough times to hit the job page
2016-09-01 15:46:16 +01:00
def test_should_not_show_cancelled_job(
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,
Don’t show cancelled jobs anywhere The information about a job doesn’t make sense if a job is cancelled. We could change the information to reflect that the job won’t be sent/ wasn’t sent/was cancelled, but there’s nothing you can really do with this info. So instead let’s: - hide cancelled jobs from the dashboard - hide cancelled jobs from the jobs page - 404 the page if the user tries to click back enough times to hit the job page
2016-09-01 15:46:16 +01:00
active_user_with_permissions,
mock_get_cancelled_job,
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
fake_uuid,
Don’t show cancelled jobs anywhere The information about a job doesn’t make sense if a job is cancelled. We could change the information to reflect that the job won’t be sent/ wasn’t sent/was cancelled, but there’s nothing you can really do with this info. So instead let’s: - hide cancelled jobs from the dashboard - hide cancelled jobs from the jobs page - 404 the page if the user tries to click back enough times to hit the job page
2016-09-01 15:46:16 +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
client_request.get(
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
'main.view_job',
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
service_id=SERVICE_ONE_ID,
job_id=fake_uuid,
_expected_status=404,
)
Don’t show cancelled jobs anywhere The information about a job doesn’t make sense if a job is cancelled. We could change the information to reflect that the job won’t be sent/ wasn’t sent/was cancelled, but there’s nothing you can really do with this info. So instead let’s: - hide cancelled jobs from the dashboard - hide cancelled jobs from the jobs page - 404 the page if the user tries to click back enough times to hit the job page
2016-09-01 15:46:16 +01:00
more test fixes & letter trimming
2022-11-22 22:50:47 -05:00
@freeze_time("2016-01-01 05:00:00.000001")
Make job page poll for updates This is a first go at having the job page update without refreshing. The approach I’ve taken is to do all the rendering of HTML on the server side, rather than use a Javascipt templating engine like mustache. This ensures that we don’t have to maintain two sets of templates. So the approach is to split the job page into partials. These partials can then: - be included in the job page to render the whole page - be rendered indivudually and then returned as a blob of HTML inside a JSON response Then I’ve added a Javascript module which looks for areas of the page that should be reloaded. For each area of the page it will poll a URL and re-render that section of the page when it gets new HTML. It implements some throttling so that API calls will never happen more frequently than 0.67 times/second.
2016-03-02 17:36:20 +00:00
def test_should_show_updates_for_one_job_as_json(
Stop using `logged_in_client` fixture We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `logged_in_client`. This is not as good because: - it returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests using `logged_in_client` to: use `client_request` instead.
2021-12-31 12:08:14 +00:00
client_request,
Make job page poll for updates This is a first go at having the job page update without refreshing. The approach I’ve taken is to do all the rendering of HTML on the server side, rather than use a Javascipt templating engine like mustache. This ensures that we don’t have to maintain two sets of templates. So the approach is to split the job page into partials. These partials can then: - be included in the job page to render the whole page - be rendered indivudually and then returned as a blob of HTML inside a JSON response Then I’ve added a Javascript module which looks for areas of the page that should be reloaded. For each area of the page it will poll a URL and re-render that section of the page when it gets new HTML. It implements some throttling so that API calls will never happen more frequently than 0.67 times/second.
2016-03-02 17:36:20 +00:00
service_one,
Update the jobs and activity page to show the user that created the job.
2016-05-11 11:57:31 +01:00
active_user_with_permissions,
Functionality added to existing endpoint without a user_has_permission decorator, tests passing. Fix tests.
2016-03-23 12:15:57 +00:00
mock_get_notifications,
Revert "Merge pull request #1336 from alphagov/revert-show-notifications" This reverts commit 7e354ff341172041d6141b50833af6262308fcb4, reversing changes made to 6f3bcff32fbfc78b4df0558d08605a260786112f.
2017-06-24 17:12:45 +01:00
mock_get_service_template,
Fixed download bug for services with api notifications. Re-organised the mock job and job_json methods.
2016-05-24 12:34:29 +01:00
mock_get_job,
Cache service data retention in Redis Adds caching for service data retention. This removes separate API client methods to retrieve individual data retention records by id or type in favor of a single method that fetches and caches all retention settings configured for the service. This makes it much easier to invalidate cache when settings change. Lookup by id or type is provided by helper methods in the service model.
2018-12-03 17:19:38 +00:00
mock_get_service_data_retention,
Fixed download bug for services with api notifications. Re-organised the mock job and job_json methods.
2016-05-24 12:34:29 +01: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
fake_uuid,
Make job page poll for updates This is a first go at having the job page update without refreshing. The approach I’ve taken is to do all the rendering of HTML on the server side, rather than use a Javascipt templating engine like mustache. This ensures that we don’t have to maintain two sets of templates. So the approach is to split the job page into partials. These partials can then: - be included in the job page to render the whole page - be rendered indivudually and then returned as a blob of HTML inside a JSON response Then I’ve added a Javascript module which looks for areas of the page that should be reloaded. For each area of the page it will poll a URL and re-render that section of the page when it gets new HTML. It implements some throttling so that API calls will never happen more frequently than 0.67 times/second.
2016-03-02 17:36:20 +00:00
):
Remove temporary `raw_response` argument We added a new argument to `client_request.get` and `client_request.post` to specify that it should return a raw `Response` object rather than an instance of `BeautifulSoup`. This is useful because sometimes we need to look at stuff like the response headers. However it turns out we already have a separate method for this, so rather than invent something new I think it’s better to stick with the thing we already have.
2021-12-31 12:16:12 +00:00
response = client_request.get_response(
Stop using `logged_in_client` fixture We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `logged_in_client`. This is not as good because: - it returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests using `logged_in_client` to: use `client_request` instead.
2021-12-31 12:08:14 +00:00
'main.view_job_updates',
service_id=service_one['id'],
job_id=fake_uuid,
)
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
content = json.loads(response.get_data(as_text=True))
assert 'sending' in content['counts']
assert 'delivered' in content['counts']
assert 'failed' in content['counts']
assert 'Recipient' in content['notifications']
Replace UK phone numbers in tests with US numbers
2022-12-22 22:11:07 -05:00
assert '2021234567' in content['notifications']
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert 'Status' in content['notifications']
assert 'Delivered' in content['notifications']
assert '12:01am' in content['notifications']
assert 'Sent by Test User on 1 January at midnight' in content['status']
Notification history page added and pagination, tests all working.
2016-03-16 16:57:10 +00:00
more test fixes & letter trimming
2022-11-22 22:50:47 -05:00
@freeze_time("2016-01-01 05:00:00.000001")
bump utils to fix datetime formatting jinja bug
2020-01-28 10:32:21 +00:00
def test_should_show_updates_for_scheduled_job_as_json(
Stop using `logged_in_client` fixture We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `logged_in_client`. This is not as good because: - it returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests using `logged_in_client` to: use `client_request` instead.
2021-12-31 12:08:14 +00:00
client_request,
bump utils to fix datetime formatting jinja bug
2020-01-28 10:32:21 +00:00
service_one,
active_user_with_permissions,
mock_get_notifications,
mock_get_service_template,
mock_get_service_data_retention,
mocker,
fake_uuid,
):
mocker.patch('app.job_api_client.get_job', return_value={'data': job_json(
service_one['id'],
created_by=user_json(),
job_id=fake_uuid,
more test fixes & letter trimming
2022-11-22 22:50:47 -05:00
scheduled_for='2016-06-01T18:00:00+00:00',
processing_started='2016-06-01T20:00:00+00:00',
bump utils to fix datetime formatting jinja bug
2020-01-28 10:32:21 +00:00
)})
Remove temporary `raw_response` argument We added a new argument to `client_request.get` and `client_request.post` to specify that it should return a raw `Response` object rather than an instance of `BeautifulSoup`. This is useful because sometimes we need to look at stuff like the response headers. However it turns out we already have a separate method for this, so rather than invent something new I think it’s better to stick with the thing we already have.
2021-12-31 12:16:12 +00:00
response = client_request.get_response(
Stop using `logged_in_client` fixture We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `logged_in_client`. This is not as good because: - it returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests using `logged_in_client` to: use `client_request` instead.
2021-12-31 12:08:14 +00:00
'main.view_job_updates',
service_id=service_one['id'],
job_id=fake_uuid,
)
bump utils to fix datetime formatting jinja bug
2020-01-28 10:32:21 +00:00
content = response.json
assert 'sending' in content['counts']
assert 'delivered' in content['counts']
assert 'failed' in content['counts']
assert 'Recipient' in content['notifications']
Replace UK phone numbers in tests with US numbers
2022-12-22 22:11:07 -05:00
assert '2021234567' in content['notifications']
bump utils to fix datetime formatting jinja bug
2020-01-28 10:32:21 +00:00
assert 'Status' in content['notifications']
assert 'Delivered' in content['notifications']
assert '12:01am' in content['notifications']
Fix incorrect processing started time on jobs We were doing the UTC to BST conversion twice, meaning the job was shown as being started 2 hours later than UTC, and 1 hour later than actual BST.
2020-09-28 14:53:42 +01:00
assert 'Sent by Test User on 1 June at 4:00pm' in content['status']
bump utils to fix datetime formatting jinja bug
2020-01-28 10:32:21 +00:00
Add tests for `time_left` This commit extracts the code that works out the ‘Data available for…’ message so that it’s easy to unit test for.
2016-07-20 11:50:22 +01:00
@pytest.mark.parametrize(
"job_created_at, expected_message", [
("2016-01-10 11:09:00.000000+00:00", "Data available for 7 days"),
("2016-01-04 11:09:00.000000+00:00", "Data available for 1 day"),
time_left considers flexible data retention periods Also update tests
2018-11-26 15:15:06 +00:00
("2016-01-03 11:09:00.000000+00:00", "Data available for 12 hours"),
Add tests for `time_left` This commit extracts the code that works out the ‘Data available for…’ message so that it’s easy to unit test for.
2016-07-20 11:50:22 +01:00
("2016-01-02 23:59:59.000000+00:00", "Data no longer available")
]
)
@freeze_time("2016-01-10 12:00:00.000000")
def test_time_left(job_created_at, expected_message):
assert get_time_left(job_created_at) == expected_message
Reference in New Issue Copy Permalink