Question

when you write a test for the logic layer, you mock the data access layer that’s used, because you don’t want the test cases to be dependent on each other.

But what about lookup tables ?
lets say you have a logic that calculcates value depending on size in Sizes table:

Small 1
Medium 2
Large 3

Now, do you mock this table somehow in your test? using a dictionary for ex.? when the table changes (a real config table will contain hundreds of values, and sometimes will not be in simple key-value form) how do you keep code and table insync?

or you bend this rule… and get values directly from database?
but what if tomorrow i change the data source? or i cannot access the database somehow? aren’t test cases supposed to run in whatever conditions ?

what’s the best approach?

Answer 1

I would still mock the lookup table, even if for the ‘happy’ testing scenarios you just return the real data returned from the database.

But then you have the flexibility to test edge cases, e.g. where data has been deleted from the database, or if no data is returned.

e.g.

// Happy tests:
Mock.Setup for GetLookupData() => return FetchRealDataHere();
Assert.AreEqual(3, Mock.Object.CountOfSizes()); // Ensure that Small, Medium and Large
... Do Good scenario unit Tests here

// Test Edge cases / destructive tests
Mock.Setup for GetLookupData() => return new Collection() [{ Small, 1}] [{ Medium 2}] -   // But omit large
... Exception case Unit tests here, e.g. Try and Insert a Large product here.

// Test empty collection
Mock.Setup for GetLookupData() => return new Collection() [Empty]
//  Assert that "NoItemsFoundException" was thrown by your logic here

// Handle empty collection
Mock.Setup for GetLookupData() => return new Collection() [Empty]

Edit I’ve updated the pseudo Mock setup / Unit test code for the updated comment below.