Our previous test ws returning a notification without a `sent_by`
attribute, which meant that cost was always 0.
Unfortunately, this meant that returning a real value for cost was
untested and (whaddya know) it broke immediately.
Old test scenario:
- billable_units=1, sent_by=None, cost=0
New scenarios
- billable_units=0, sent_by='mmg', cost=0
- billable_units=1, sent_by='mmg', cost=1
Emualated the validation methods that exist [in the python-client](620e5f7014/integration_test/__init__.py).
The `validate_v0` function loads json schemas from a local
`/schemas` directory, whereas the new `validate` function (which
we're going to use for our v2 API calls) uses the common
`get_notification_response` python schema defined in
"app/v2/notifications/notification_schemas.py".
Removed the new `v2` schema from the last commit as it's no longer
being used.
Also, refactored common code in the GET and POST contract files
so that making requests and converting responses to JSON are
pulled out into common functions.
Converted python-based schema in
"app/v2/notifications/notification_schema.py" into a pure json
schema and tested it with the new "v2/" API route to confirm that
it validates.
Also refactored some common code in the public contract GET tests
that returns notifications.
We're formally using the ISO 8601 UTC datetime format, and so the
correct way to output the data is by appending the timezone.
("Z" in the case of UTC*).
Unfortunately, Python's `datetime` formatting will just ignore the
timezone part of the string on output, which means we just have to
append the string "Z" to the end of all datetime strings we output.
Should be fine, as we will only ever output UTC timestamps anyway.
* https://en.wikipedia.org/wiki/ISO_8601#UTC
This is the schema that individual notifications will conform to
when they are returned from this API.
JSON logic enforces that the right keys are set depending on the
`"type"`. (eg a schema with `"type": "sms"` must have a
`"phone_number"` value and it cannot have an `"email_address"`)
The new 'v2' API wants to return less data than the previous one,
which was sending back tons of fields the clients never used.
This new route returns only useful information, with the JSON
response dict being built up in the model's `.serialize()` method.
Note that writing the test for this was a bit painful because of
having to treat loads of keys differently. Hopefully we think this
is a good way to write this test, because if we don't, we should
start thinking of a better way to check the values are what we
expect.
In the V2 API, the GET response for an individual notification
returns a 'cost' value, which we can get by multiplying the
billable units by the per-message rate of the supplier who
sent the message.
Any notifications with billable units > 0 but without a
corresponding `ProviderRates` entry will blow up the application,
so make sure you've got one.
Update the format_checkers to raise the specific exception that why the validator can handle multiple messages.
Which led to a refactor of build_error_message.
Two different versions of 0059 were merged.
`0059_set_services_to_active` was merged first, so this renames my
migration to `0060`, so it goes in afterwards.
