[x] Are you working against an Issue?
Related to #211
After #409 got merged, I looked at the issue tracker and realized the PR also fixed another issue i.e., #211. PR #409 introduced the behavior that at the start of the update (both autonomous and interactive) the root fields are shifted to installer level and any previous values are overwritten by the root values.
Expected flow:
1) Installer level fields are overridden by root fields at the start of the update.
2) The update flow modifies the installer level fields if needed. (e.g. ProductCode in case of MSI upgrade)
3) At the end of the update, the common installer fields are moved to the root level.
So now, you won't get a behavior of root fields and installer fields being different/not updated as described in the linked issue.
This PR simply adds a test case to verify this behavior. The root values are different from installer level and will become common between all installers after the override so they're shifted back to the root at the end of the update. I know I may been overkill with the assert statements but just wanted to be very sure 😄 Though I wish there was a way to update the ProductCode in the test update for more coverage.
After #409 got merged, I looked at the issue tracker and realized the PR also fixed another issue i.e., #211. PR #409 introduced the behavior that at the start of the update (both autonomous and interactive) the root fields are shifted to installer level and any previous values are overwritten by the root values.
Expected flow: 1) Installer level fields are overridden by root fields at the start of the update. 2) The update flow modifies the installer level fields if needed. (e.g. ProductCode in case of MSI upgrade) 3) At the end of the update, the common installer fields are moved to the root level.
So now, you won't get a behavior of root fields and installer fields being different/not updated as described in the linked issue.
This PR simply adds a test case to verify this behavior. The root values are different from installer level and will become common between all installers after the override so they're shifted back to the root at the end of the update. I know I may been overkill with the assert statements but just wanted to be very sure 😄 Though I wish there was a way to update the ProductCode in the test update for more coverage.
Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-create/pull/413&drop=dogfoodAlpha