Is there a proper way to setup and use fake data in development for a DDD project using DI?

Question

I have a project that has a DD design, and also uses dependency injection. During development, we connect to a test database which contains a former snapshot of production. This works well 95% of the time. However, for some processes that we have to implement into our application, the underlying SQL statements, (of which I can't control and are developed by a third party) are slow. Some of these procedures can take 30 seconds while even others might take over 5 minutes to execute.

Our UI's rely on this data and, unfortunately, our users understand that there are some tasks they have to start and just wait for the data to arrive. For now, I'm not asking for ways to speed up the final application. Simply put, there are just to many factors outside of our control and this limitation has to be accepted as part of the final result.

However, while developing the UI I do require a responsive return of results from my domain. To do this, I've setup fake repositories within my application project. Specifically, I have an ASP.Net project that initializes all of the DI components within the AppHost. It is hear that all repos are injected into the container, followed by the respective domains, which are then used by the ASP.Net APIs that are utilized by the web page UI.

So far, what I've done has been to create fake repositories from within ASP.Net project. Within the AppHost, I have an #ifdef FAKES preprocessor that checks to see if I've specified that I'd like to use the fake repos, and it then loads the fakes, rather than the legit ones which are used during normal testing and eventually production.

This work but feels... wrong. Maybe this is the correct approach, but I feel as if there has to be a better way of injecting fake data repos into my application for development. Is there a better appraoch for this purpose?

One requirement is that I do not want to always access this faked data in development. While building UIs, I often could care less about what the data looks like, so long as something is there that has the right data types and string lengths. However, once it's time to test implementation, I will always have to wait for the legitimate test data to load from our test servers.

Just to be clear, these fakes are not for unit testing. In this context, I am strictly creating fake repositories so that I'm getting data back in milliseconds, rather than 2-3 minutes. Is there a better way of implementing and loading these context-specific development fakes?

Answer 1

Given the feedback that you provided, then the use of fakes is entirely justified. Given the desire to be able to quickly switch between the fakes and the real data, you may want to make the use of the fakes driven by the existence of a DLL.

The solution would look like this:

• Create an assembly to contain the implementations for your fakes.
  • Interface definition and common model code should live in a root assembly
  • The fakes assembly would reference that root assembly
  • The actual implementation assembly would also reference the root assembly
• Check if the assembly exists in the application directory at run time
  • If it exists, set up the DI container to use the fake

You can put the whole dynamic loading functionality inside a #if DEBUG section of code, so it doesn't slip into production. Alternatively, you can make the choice of which assembly to load be a parameter that is read after the application is launched. That will allow you to quickly and easily swap out fakes without recompiling.

---

Original answer which is still valid for smaller systems

There are two things I recommend you do:

• Get a DBA to figure out if you need to add indexes, the right indexes can improve the speed of a query by several orders of magnitude
• Set up a test database with the minimal set of data to put the UI through its paces, so the queries run quickly even if it is not optimized

When you need the fast response times, connect to the minimal database. When you need to validate the correctness of the application, connect to the backup of production.

While you may not be in control of the queries, you should be able to influence the schema. Using the backup of production, you can judiciously add indexes to improve the performance of the queries. If the performance is sufficiently improved, get it pushed to production.