1

I have a relatively large web api application, i.e. it currently has ~300 tables.

The app is written in such a way that it doesn't use any stored procedures and next to no views, i.e. the business logic is all in the app code. It uses the repository pattern so it is relatively easy to create mock data for our unit tests.

However, it is quite hard to manage the mock data, and very hard for any given individual to get insight into what data is already there. We've tried to move the test data into a mock factory, so that it is stored in a single file, which various tests then load as needed (i.e. a given test will only require a certain subset of the data, so it will only ask for that subset).

Still, the management of the data is quite complex, asserting about the data returned from the application is also fragile. For instance, say that there are defined 10 customers in our mock data, out of which 2 are marked as inactive. We may have a test case which tests that a method which should return all active customers should return 8 instances. However, if a developer must add a new instance to our test data, this will break existing tests/asserts.

Does anyone have experience in managing this, or has anything been written about this?

Community
  • 1
  • 1
dabs
  • 727
  • 1
  • 7
  • 23
  • Use specific mocks for each test i.e don't share the data. Also, a concrete (anonymized) code sample would help more. – MikeSW May 18 '14 at 16:55

1 Answers1

0

It sounds like you are creating a test data that is used for multiple tests. This isn't the best solution. You should create the data you need on a per test basis. The test data builder pattern should help you here. This link describes how you would use test data builder. Also, Mark Seemann has written a library that will help build this sort of mock data it's called autofixture.

He has a great video on PluralSight on advanced unit testing. If you have access to PluralSight I would recommend watching the video.

Andrew
  • 5,215
  • 1
  • 23
  • 42
  • Yes this is correct, and I agree that this has its downsides. Creating test data for each test has its own downsides as well, i.e. it might result in duplicate data. I guess there is a middle road there somewhere, I just need to find it. – dabs May 19 '14 at 16:29
  • I am not sure that I follow. If you take your example above and apply a test data builder, the builder would look something like. var cust1 = CreateCustomerBuilder().WithInactiveSetTo(true).Build(); var cust2 CreateCustomerBuilder().WithInactiveSetTo(false).Build(); You don't need any more rows to test the if an inactive customer is created. You also don't need to know the values for any other properties of the customer. The test data builder can assign random values. – Andrew May 20 '14 at 08:10