Add NALD test data to permit licence helper #1049
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
https://eaflood.atlassian.net/browse/WATER-3981 The [water-abstraction-service](https://gitub.com/DEFRA/water-abstraction-service) has a mechanism for seeding data for testing that relies on loading in YAML fixture files, sort of. Some content comes from these, but other stuff is hard-coded into the 'loaders'. Long story short we're going to replace it with something simpler yet more flexible! Our new solution is going to be based on the hard work we've already invested making our test helpers. We use these to quickly create meaningful records in the DB which we can then write unit tests against. So, why not reuse them to do the same for our acceptance tests!? One key difference with the unit tests is we are only driving the app through our code. Anything external we mock or stub. The acceptance tests do not have that luxury which means any record we create has to support not only this app but the legacy ones. The good news is we can do nearly all that with the existing helper data and functionality. The one key bit missing is the `licence_data_value` for a `permit.licence`. In real life, when a licence is imported from NALD into WRLS a number of records get created. A lot of it is duplication, but not _everything_ from NALD is put into tables. This seems to stem from an early architectural decision that WRLS would be building a generic 'permit' repository. Some top level information is captured in `permit.licence`. But because it needed to be 'generic' everything (_everything_ 😱) from NALD gets dumped into the JSONB field `licence_data_value`. The problem is, when the previous team built a feature that needed info only held in `licence_data_value`, rather than put it into a table, they just dipped into the JSON. And they did this again, and again, and _again_! You cannot even load a licence in the UI without having this field properly populated. And that means it'll block our acceptance test data loading solution if we don't put something 'real' into it. So, this change adds the _ugliest_ bit of JSON you'll ever have clapped eyes on. 🤢🤮 We add it to the helper and by default load it into the field. It doesn't really matter that the data is, it just has to have a structure that won't make the legacy apps go 💥. The data is taken from the [water-abstraction-service](https://github.com/DEFRA/water-abstraction-service/blob/main/integration-tests/billing/services/permit-helpers.js) and its existing acceptance test data loading solution.
Cruikshanks
added
the
housekeeping
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://eaflood.atlassian.net/browse/WATER-3981
The water-abstraction-service has a mechanism for seeding data for testing that relies on loading in YAML fixture files, sort of. Some content comes from these, but other stuff is hard-coded into the 'loaders'.
Long story short, we're going to replace it with something simpler yet more flexible!
Our new solution is going to be based on the hard work we've already invested in making our test helpers. We use these to quickly create meaningful records in the DB which we can then write unit tests against. So, why not reuse them to do the same for our acceptance tests!?
One key difference with the unit tests is we are only driving the app through our code. Anything external we mock or stub. The acceptance tests do not have that luxury which means any record we create has to support not only this app but the legacy ones.
The good news is we can do nearly all that with the existing helper data and functionality. The one key bit missing is the
licence_data_valuefor apermit.licence. In real life, when a licence is imported from NALD into WRLS a number of records get created. A lot of it is duplication, but not everything from NALD is put into tables.This seems to stem from an early architectural decision that WRLS would be building a generic 'permit' repository. Some top level information is captured in
permit.licence. But because it needed to be 'generic' everything (everything 😱) from NALD gets dumped into the JSONB fieldlicence_data_value. The problem is, when the previous team built a feature that needed info only held inlicence_data_value, rather than put it into a table, they just dipped into the JSON. And they did this again, and again, and again!You cannot even load a licence in the UI without having this field properly populated. And that means it'll block our acceptance test data loading solution if we don't put something 'real' into it.
So, this change adds the ugliest bit of JSON you'll ever have clapped eyes on. 🤢🤮
We add it to the helper and by default load it into the field. It doesn't really matter that the data is, it just has to have a structure that won't make the legacy apps go 💥. The data is taken from the water-abstraction-service and its existing acceptance test data loading solution.