Add company address model and relationships #1140
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 We recently [added a new acceptance test data loader](https://eaflood.atlassian.net/browse/WATER-3981) to replace the slow and flaky legacy acceptance test data loader in [water-abstraction-service](https://github.com/DEFRA/water-abstraction-service). However a couple of our acceptance tests fail when using our new test data. After investigation it turns out that the legacy charge information setup journey relies on their being a `crm_v2.company_addresses` record linking a company to its addresses. It can find the companies linked to our licence. But once you select the company to use it then goes looking for the possible addresses. With the old test data you get to pick from 2 because there are `crm_v2.company_addresses`. With our new test data you are taken to the enter a postcode screen as a fallback to the legacy code not finding any addresses. At the moment this is the only reason we've come across that depends on this table. But we need it to make this journey work. SO, this change adds the model and links it to `CompanyModel`. We then ensure it is cleaned down in the tear-down and available in our data loader.
Cruikshanks
added a commit
to DEFRA/water-abstraction-acceptance-tests
that referenced
this pull request
Jun 26, 2024
https://eaflood.atlassian.net/browse/WATER-3981 In [Switch to new test data loader for SROC billing](#90) we started the move to a new acceptance test data loader to replace the slow and flaky legacy one. 😍🫶 We _swear_ all the tests were passing before we merged. But low and behold a number are failing. When we dug in we found its because there are tests referring to the old licence reference. Clearly, we must have imagined the passing tests! 🤦 But we also found that those that rely on adding a new charge version were also broken because our fixture wasn't creating data that the legacy charge version setup journey requires. We added the ability to create the data needed in [Add company address model and relationships](DEFRA/water-abstraction-system#1140). This change updates our SROC billing fixture and all the references to the old licence reference.
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
We recently added a new acceptance test data loader to replace the slow and flaky legacy acceptance test data loader in water-abstraction-service.
However, a couple of our acceptance tests fail when using our new test data. After investigation, it turns out that the legacy charge information setup journey relies on their being a
crm_v2.company_addressesrecord linking a company to its addresses.It can find the companies linked to our licence. But once you select the company to use it then goes looking for the possible addresses. With the old test data you get to pick from 2 because there are
crm_v2.company_addresses. With our new test data you are taken to the enter a postcode screen as a fallback to the legacy code not finding any addresses.At the moment this is the only reason we've come across that depends on this table. But we need it to make this journey work.
SO, this change adds the model and links it to
CompanyModel. We then ensure it is cleaned down in the tear-down and available in our data loader.