Note that there are some explanatory texts on larger screens.

plurals
  1. POHow to Test Functions w/ Complex Data Interactions
    primarykey
    data
    text
    <p>Currently, I am working on system that does quite a bit of reporting-style functions that consumes many different data points and transforms them into larger, sometimes flattened outputs. Most of my app is built upon a variation of the repository pattern. Due to this, I have a suite of mock-repositories that I use for testing scenarios. The problem that I am running into is that the interaction between these data points is so complex that it is quickly become a maintenance nightmare to maintain the "mock data". Here is a mock example:</p> <pre><code>public class SomeReportingEntity { private IProductRepo ProductRepo; private IManagerRepo ManagerRepo; private ILocationRepo LocationRepo; private IOrdersService OrdersService; private IEmployeeRepo EmployeeRepo; public ReportingEntity(IProductRepo ipr, IManagerRepo imr, ILocationRepo ilr, IOrdersService ios, IEmployeeRepo ier){ //Load these to private vars... } //This is the function that I want to test... public SomeReportingEntity GetManagerSalesByRegionReport() { //Make a complex join on all sub collections. These //sub collections are all under test individually. var MangerSalesByRegionItems = From x in ProductRepo.CurrentProducts() Join y in OrdersService.FutureOrders() On ... Join z in EmployeeRepo.ActiveEmployees() On ... Join a in LocationRepo.GetAllRegions() On ... Join b In ManagerRepo.GetActiveManagers On ... Select new SomeReportingEntity() With { ... } return MangerSalesByRegionItems.ToList(); } </code></pre> <p>}</p> <p>Admittedly, this is a very contrived example but the basic idea that I want to emphasize is that I have several repositories that I am joining and I need to create many tests to ensure that this complex query does as expected. Due to the fact that the joining operations are so complex, it makes the mock data VERY difficult to keep in line - especially as I have to add more associations and test additional points. In addition, I need to be able to enter specific record states into the mocks (such as an employee lacking an assigned manager) to verify that query handles those situations appropriately.</p> <p>So here are my questions:</p> <ol> <li>What is the best way to "mock" this data so that it is not such a matinenance nightmare? I have had many people suggest building an in-memory database to support this.</li> <li>Am I really suffering from an architecture issue here? In reporting scenarios, I find myself in this pattern quite a bit where I take many disassociated data points and merge them into a new, hybrid entity. With the onset of Linq, it is very easy to do and has high clarity of intent, but sometimes it feels like I am cheating a little.</li> </ol>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload