After some hours of frustration and asking myself whether I should have used Unit of Work in the first place (there are already layers of abstraction in the standard .NET Core template project) I managed to get a functioning xUnit test method that mocks the repositories, populates them with data and verifies the model returned by a controller method.
Setting Up a Unit Test Project Add a xUnit project to the solution, then add an assembly reference in that to the project being tested.
A repository pattern exists to add another layer of abstraction between the application logic and the data layer, using dependency injection to decouple the two. It’s not my preferred way of doing things, because of the effort and complexity involved, and I’m certainly not the only person who initially struggled to understand the concepts behind it. Plus, it’s apparent that Entity Framework makes heavy use of that dependency injection already. But a Repository Pattern is widely considered - by software engineers far more experienced than I am - best practice for engineering services that deal with critical data.
Writing at The Shape of Code blog, Derek Jones asserted that ‘Structural differences between academia and industry make it likely that research software will always be a tangled mess, only usable by the person who wrote it.’
Yes, there are structural (and insurmountable) differences between academia and industry in how programming languages are used to solve problems. Professional developers more often engineer code, because there are typically real-world consequences to releasing poor-quality software, from damage to a company’s reputation to injury or death.
