Removed address from AdditionalAddress Request + DTO - #63
Conversation
There was a problem hiding this comment.
Pull request overview
This pull request removes the deprecated address field from AdditionalAddress DTOs and related tests. The field was already marked as deprecated and has been replaced by structured address fields (street_name, house_number, address_addition).
Changes:
- Removed deprecated
addressfield fromCreateEditAdditionalAddressDTOandAdditionalAddressDTO - Updated test files to remove the
addressfield from test data - Updated JSON fixture to reflect API response without
addressfield - Changed
postcodefrom string to integer in test data
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
src/Dto/AdditionalAddresses/CreateEditAdditionalAddressDTO.php |
Removed deprecated address property and its assignment in fromArray method |
src/Dto/AdditionalAddresses/AdditionalAddressDTO.php |
Removed deprecated address property and its assignment in fromArray method |
tests/Requests/AdditionalAddresses/CreateAnAdditionalAddressRequestTest.php |
Removed address field from test data and changed postcode from string to int |
tests/Requests/AdditionalAddresses/EditAnAdditionalAddressRequestTest.php |
Removed address field from test data and changed postcode from string to int |
tests/Fixtures/Saloon/AdditionalAddresses/create-an-additional-address.json |
Updated JSON response fixture to remove address field |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| description: 'Test description', | ||
| address: 'Test address', | ||
| postcode: '12345', | ||
| postcode: 12345, |
There was a problem hiding this comment.
The postcode value is being passed as an integer (12345) in the test, but the CreateEditAdditionalAddressDTO expects it as ?int while the API returns it as a string ("12345" in the fixture). There's a type inconsistency between what the test passes, what the DTO expects, and what the API returns. Since AdditionalAddressDTO (the response DTO) defines postcode as ?string, this change to an integer literal in the test exacerbates the type mismatch. Consider using a string value '12345' instead to align with the API response format.
| postcode: 12345, | |
| postcode: '12345', |
| description: 'Test description edited', | ||
| address: 'Test address edited', | ||
| postcode: '12345', | ||
| postcode: 12345, |
There was a problem hiding this comment.
The postcode value is being passed as an integer (12345) in the test, but the CreateEditAdditionalAddressDTO expects it as ?int while the API returns it as a string ("12345" in fixtures). There's a type inconsistency between what the test passes, what the DTO expects, and what the API returns. Since AdditionalAddressDTO (the response DTO) defines postcode as ?string, this change to an integer literal in the test exacerbates the type mismatch. Consider using a string value '12345' instead to align with the API response format.
| postcode: 12345, | |
| postcode: '12345', |
No description provided.