If you try to change the value of a Master-Detail field that is not configured so that "child records can be reparented," you will not see an error. Salesforce will simply leave the existing value in place as if you never attempted to make the change in the first place.
The interesting implication here is that developers should write Apex tests to validate expected an Master-Detail configuration. Admins and developers can work together more reliably, if you explicitly write an Apex test that confirms whether a Master-Detail field can be reparented. This way, when an admin changes the field configuration and unintentionally breaks something, a red flag will be raised by the test method, pointing you clearly to the unexpected configuration change.
To see what happens if you reparent a child record when that's not "allowed", try this:
- Create a custom object labeled "Alias" (Alias__c), with the record name configured as a text field
- Create a Master-Detail field on Alias labeled "Account" (Account__c)
- Configure the Account field on Alias so that child records cannot be reparented to other parent records after they are created
- Create an AliasUtilTest class, as seen in this paste, with a test method to assert that changing the Account field on an alias is a futile effort
- Run the test method in AliasUtilTest
