darkhelm/notifications-api
1
0
Fork 0
mirror of https://github.com/GSA/notifications-api.git synced 2025-12-22 08:21:13 -05:00
Code Issues Packages Projects Releases Wiki Activity
Files
19dcd7a48b6f06ea33bc1ee0635c34c8f9df199d
notifications-api/tests/app/dao/test_email_branding_dao.py

47 lines
1.4 KiB
Python
Raw Normal View History

create, edit and use email branding instead of organisation notable things that have been kept until migration is complete: * passing in `organisation` to update_service will update email branding * both `/email-branding` and `/organisation` hit the same code * service endpoints still return organisation as well as email branding
2018-02-05 12:02:35 +00:00
from app.dao.email_branding_dao import (
dao_get_email_branding_by_id,
Find email_branding by name
2018-07-30 13:27:49 +01:00
dao_get_email_branding_by_name,
create, edit and use email branding instead of organisation notable things that have been kept until migration is complete: * passing in `organisation` to update_service will update email branding * both `/email-branding` and `/organisation` hit the same code * service endpoints still return organisation as well as email branding
2018-02-05 12:02:35 +00:00
dao_update_email_branding,
)
from app.models import EmailBranding
from tests.app.db import create_email_branding
remove usage of notify_db fixture in unit tests * notify_db fixture creates the database connection and ensures the test db exists and has migrations applied etc. It will run once per session (test run). * notify_db_session fixture runs after your test finishes and deletes all non static (eg type table) data. In unit tests that hit the database (ie: most of them), 99% of the time we will need to use notify_db_session to ensure everything is reset. The only time we don't need to use it is when we're querying things such as "ensure get X works when database is empty". This is such a low percentage of tests that it's easier for us to just use notify_db_session every time, and ensure that all our tests run much more consistently, at the cost of a small bit of performance when running tests. We used to use notify_db to access the session object for manually adding, committing, etc. To dissuade usage of that fixture I've moved that to the `notify_db_session`. I've then removed all uses of notify_db that I could find in the codebase. As a note, if you're writing a test that uses a `sample_x` fixture, all of those fixtures rely on notify_db_session so you'll get the teardown functionality for free. If you're just calling eg `create_x` db.py functions, then you'll need to make you add notify_db_session fixture to your test, even if you aren't manually accessing the session.
2022-05-03 17:00:51 +01:00
def test_get_email_branding_by_id_gets_correct_email_branding(notify_db_session):
create, edit and use email branding instead of organisation notable things that have been kept until migration is complete: * passing in `organisation` to update_service will update email branding * both `/email-branding` and `/organisation` hit the same code * service endpoints still return organisation as well as email branding
2018-02-05 12:02:35 +00:00
email_branding = create_email_branding()
email_branding_from_db = dao_get_email_branding_by_id(email_branding.id)
assert email_branding_from_db == email_branding
remove usage of notify_db fixture in unit tests * notify_db fixture creates the database connection and ensures the test db exists and has migrations applied etc. It will run once per session (test run). * notify_db_session fixture runs after your test finishes and deletes all non static (eg type table) data. In unit tests that hit the database (ie: most of them), 99% of the time we will need to use notify_db_session to ensure everything is reset. The only time we don't need to use it is when we're querying things such as "ensure get X works when database is empty". This is such a low percentage of tests that it's easier for us to just use notify_db_session every time, and ensure that all our tests run much more consistently, at the cost of a small bit of performance when running tests. We used to use notify_db to access the session object for manually adding, committing, etc. To dissuade usage of that fixture I've moved that to the `notify_db_session`. I've then removed all uses of notify_db that I could find in the codebase. As a note, if you're writing a test that uses a `sample_x` fixture, all of those fixtures rely on notify_db_session so you'll get the teardown functionality for free. If you're just calling eg `create_x` db.py functions, then you'll need to make you add notify_db_session fixture to your test, even if you aren't manually accessing the session.
2022-05-03 17:00:51 +01:00
def test_get_email_branding_by_name_gets_correct_email_branding(notify_db_session):
Find email_branding by name
2018-07-30 13:27:49 +01:00
email_branding = create_email_branding(name="Crystal Gems")
email_branding_from_db = dao_get_email_branding_by_name("Crystal Gems")
assert email_branding_from_db == email_branding
remove usage of notify_db fixture in unit tests * notify_db fixture creates the database connection and ensures the test db exists and has migrations applied etc. It will run once per session (test run). * notify_db_session fixture runs after your test finishes and deletes all non static (eg type table) data. In unit tests that hit the database (ie: most of them), 99% of the time we will need to use notify_db_session to ensure everything is reset. The only time we don't need to use it is when we're querying things such as "ensure get X works when database is empty". This is such a low percentage of tests that it's easier for us to just use notify_db_session every time, and ensure that all our tests run much more consistently, at the cost of a small bit of performance when running tests. We used to use notify_db to access the session object for manually adding, committing, etc. To dissuade usage of that fixture I've moved that to the `notify_db_session`. I've then removed all uses of notify_db that I could find in the codebase. As a note, if you're writing a test that uses a `sample_x` fixture, all of those fixtures rely on notify_db_session so you'll get the teardown functionality for free. If you're just calling eg `create_x` db.py functions, then you'll need to make you add notify_db_session fixture to your test, even if you aren't manually accessing the session.
2022-05-03 17:00:51 +01:00
def test_update_email_branding(notify_db_session):
create, edit and use email branding instead of organisation notable things that have been kept until migration is complete: * passing in `organisation` to update_service will update email branding * both `/email-branding` and `/organisation` hit the same code * service endpoints still return organisation as well as email branding
2018-02-05 12:02:35 +00:00
updated_name = 'new name'
create_email_branding()
email_branding = EmailBranding.query.all()
assert len(email_branding) == 1
assert email_branding[0].name != updated_name
dao_update_email_branding(email_branding[0], name=updated_name)
email_branding = EmailBranding.query.all()
assert len(email_branding) == 1
assert email_branding[0].name == updated_name
Add unique constraint to email branding domains Does two things: 1. Revert "Revert "Add unique constraint to email branding domain"" This reverts commit af9cb30ef30fe3859507a5747a65255b7466af4b. 2. Don’t allow empty string in email branding domain Columns with multiple `null`s can have a uniqueness constraint. Columns with multiple empty string values are not considered unique. This commit: - removes any duplicate empty string values - casts empty strings to null string any time these columns are updated --- Squashed into this single commits because these two things are not atomic as individual commits.
2018-09-04 10:57:47 +01:00
remove usage of notify_db fixture in unit tests * notify_db fixture creates the database connection and ensures the test db exists and has migrations applied etc. It will run once per session (test run). * notify_db_session fixture runs after your test finishes and deletes all non static (eg type table) data. In unit tests that hit the database (ie: most of them), 99% of the time we will need to use notify_db_session to ensure everything is reset. The only time we don't need to use it is when we're querying things such as "ensure get X works when database is empty". This is such a low percentage of tests that it's easier for us to just use notify_db_session every time, and ensure that all our tests run much more consistently, at the cost of a small bit of performance when running tests. We used to use notify_db to access the session object for manually adding, committing, etc. To dissuade usage of that fixture I've moved that to the `notify_db_session`. I've then removed all uses of notify_db that I could find in the codebase. As a note, if you're writing a test that uses a `sample_x` fixture, all of those fixtures rely on notify_db_session so you'll get the teardown functionality for free. If you're just calling eg `create_x` db.py functions, then you'll need to make you add notify_db_session fixture to your test, even if you aren't manually accessing the session.
2022-05-03 17:00:51 +01:00
def test_email_branding_has_no_domain(notify_db_session):
Add unique constraint to email branding domains Does two things: 1. Revert "Revert "Add unique constraint to email branding domain"" This reverts commit af9cb30ef30fe3859507a5747a65255b7466af4b. 2. Don’t allow empty string in email branding domain Columns with multiple `null`s can have a uniqueness constraint. Columns with multiple empty string values are not considered unique. This commit: - removes any duplicate empty string values - casts empty strings to null string any time these columns are updated --- Squashed into this single commits because these two things are not atomic as individual commits.
2018-09-04 10:57:47 +01:00
create_email_branding()
email_branding = EmailBranding.query.all()
Remove domain columns from branding table This relationship is via the `Organisation` now; we don’t use this column to fudge a relationship based on the user’s email address and the matching something in these columns.
2019-04-05 16:26:52 +01:00
assert not hasattr(email_branding, 'domain')
Reference in New Issue Copy Permalink