Dummy data and unit testing strategies in a modular application stack

Question

How do you manage dummy data used for tests? Keep them with their respective entities? In a separate test project? Load them with a Serializer from external resources? Or just r

Answer 1

I'm wondering if you couldn't solve your problem by changing your testing approach.

Unit Testing a module which depends on other modules and, because of that, on the test data of other modules is not a real unit test!

What if you would inject a mock for all of the dependencies of your module under test so you can test it in complete isolation. Then you don't need to setup a complete environment where each depending module has the data it needs, you only setup the data for the module your actually testing.

If you imagine a pyramid, then the base would be your unit tests, above that you have functional tests and at the top you have some scenario tests (or as Google calls them, small, medium and big tests).

You will have a huge amount of Unit Tests that can test every code path because the mocked dependencies are completely configurable. Then you can trust in your individual parts and the only thing that your functional and scenario tests will do is test if each module is wired correctly to other modules.

This means that your module test data is not shared by all your tests but only by a few that are grouped together.

The Builder Pattern as mentioned by cwash will definitely help in your functional tests. We are using a .NET Builder that is configured to build a complete object tree and generate default values for each property so when we save this to the database all required data is present.