If you are wanting to insert rows with a duplicate key into an EF DbSet, then no, this isn't possible. Keys must be unique. However, if you are trying to insert data for each test into a DbContext are getting the IdentityConflict exception since the test records have the same ID (but reflect data specific to that test) then it is because your DbContext data source is living between the tests.
Normally with testing scenarios such as integration testing the process is that a test setup or at most a test fixture setup would instantiate the DbContext to a new in-memory store and initialize the data for that test, or suite of tests. When the test/fixture tears down, the DbContext and in-memory data store is disposed. Note that this is typically done for integration tests, not unit tests specifically because while an in-memory database is a lot faster than something like SQL Express, it still means setting up and tearing down data state between each test or set of tests. Unit tests are designed to be run continuously ad-hoc while you are developing (to help flag breaking changes before you're ready to commit those changes) while integration tests would be run either just prior to a commit, or as part of the commit process.
As per my earlier answer (Entity Framework Core 3: Interface on DBContext good practice?) a good alternative for unit tests is the Repository pattern to avoid mocking an entire DbContext or requiring a setup and teardown of known data state. The unit test mock of the repository is configured to return the specific known state you want to test business logic around. Integration tests certainly are still important, but they are geared towards asserting data state behaviour all the way through the EF DbContext & Repository.
So as an example if you have a Unit Test that wants to work on a set of Orders and had an OrderRepository with a GetCustomerOrders method that returned an IQueryable<Order> then the mock of the repository can look something like this: (Moq example)
// Setting up the test data could be done in the test or a separate method.
var orders = new []
{
new Order { OrderId = 1, /* populate expected order details, including references */ },
new Order { OrderId = 2, }
}.ToList();
var mockOrderRepository = new Mock<IOrderRepository>();
mockOrderRepository.Setup(x => x.GetCustomerOrders(customerId))
.Returns(orders.AsQueryable());
IOrderService serviceUnderTest = new OrderService(mockOrderRepository.Object); // plus other mocked dependencies...
var result = serviceUnderTest.DoSomethingForCustomer(customerId);
mockOrderRepository.Verify(x => x.GetCustomerOrders(customerId), Times.Once);
// other asserts and result check...
Doing this with an in-memory database would require the in-memory database to be scoped to the test, or ensure that data referenced by the test doesn't conflict with the data referenced by any other test.
