Navigation properties override FK properties.
You are creating a new Department (ID #2) and telling it to associate to a new employee. That employee's Department ID is the FK for the relationship, so whatever you try to set it to will be ignored, that employee will now be associated to this new department (#2). The same goes for associating a record for an existing employee. All EF knows is that since you specified an ID for Employee #2 (Alice) you want to associate her to this new Department. The fact that you specified a different name, there is no change tracking to tell it that you intend to move Alice to the new department and change her name.
So EF is doing exactly what it expects to based on the actions you are taking.
If you want to re-associate Alice and change her name, load the tracked Employee entity, change the name, and add to the new department. If you want Ronaldo to be associated with Department 1, then add him to that department.
Attach is not meant to group unrelated entities to make changes, use the DbSets or tracked parent entities for that.
Something that might be more in line with what you want...
var department = new Department
{
Name = "Testing"
};
context.Departments.Add(department); // Tell EF this is a new item.
var alice = context.Employees.First(x => x.Id == 2); // Loads and tracks Alice
alice.Name = "Sharapova"; // will be picked up with change tracking
department.Employees.Add(alice); // Associate Alice/Sharapova with new department
department.Employees.Add(new Employee
{
Name = "Ronaldo",
Designation = "MD"
}); // Add new employee to new department (2)
context.SaveChanges();
If you just want to rename Alice without changing her Department then remove the department.Employees.Add(alice); This will update her name when context.SaveCHanges() is called as all tracked entities are updated. If you want to add Ronaldo to Department #1, then you should load Department #2 (including employees) and add him to that department's Employees collection.
When working with collection navigation properties (I.e. department.Employees) avoid attempting to use setters. I.e. don't have code like department.Employees = new [] { new Employee {...} } etc. especially when working with existing, tracked entities. Instead, always work with Add() and Remove() to associate and disassociate related items. Setting a new collection can lead to errors and unexpected behaviour where you might intend to replace 5 existing associations with 3 current ones, but EF interprets this as attempting to insert duplicate rows since you are just overwriting the collection, not telling it to remove specific items.