I'm trying out TDD on a greenfield hobby app in ASP.NET MVC, and have started to get test methods such as the following:

[Test]
public void Index_GetRequest_ShouldReturnPopulatedIndexViewModel()
{
    var controller = new EmployeeController();
    controller.EmployeeService = GetPrePopulatedEmployeeService();

    var actionResult = (ViewResult)controller.Index();

    var employeeIndexViewModel = (EmployeeIndexViewModel)actionResult.ViewData.Model;
    EmployeeDetailsViewModel employeeViewModel = employeeIndexViewModel.Items[0];

    Assert.AreEqual(1, employeeViewModel.ID);
    Assert.AreEqual("Neil Barnwell", employeeViewModel.Name);
    Assert.AreEqual("ABC123", employeeViewModel.PayrollNumber);
}

Now I'm aware that ideally tests will only have one Assert.xxx() call, but does that mean I should refactor the above to separate tests with names such as:

• Index_GetRequest_ShouldReturnPopulatedIndexViewModelWithCorrectID
• Index_GetRequest_ShouldReturnPopulatedIndexViewModelWithCorrectName
• Index_GetRequest_ShouldReturnPopulatedIndexViewModelWithCorrectPayrollNumber

...where the majority of the test is duplicated code (which therefore is being tested more than once and violates the "keep tests fast" advice)? That seems to be taking it to the extreme to me, so if I'm right as I am, what is the real-world meaning of the "one assert per test" advice?