One approach you could use is to test the inner loop in the same way you would a private method. That is, you don't (at least, not directly).
Instead of testing the loop itself, verify the result that is returned by GetParentAndChildObjects
.
By designating a test double for _dbRepository
, you have complete control over the details of the objects that are inserted into the parentObjects
list. As a result, your test can just verify that the returned list of objects looks as expected.
Mark Seemann describes this approach well:
After having answered the question on when to use [stubs and when to use mocks], a couple of times, I arrived at this simple rule, based on the language of Command Query Separation (CQS):
Use Mocks for Commands
Use Stubs for Queries
This makes lots of sense, because Commands are all about side effects, and Mocks are all about Behaviour Verification: that is, that side effects occurred. Stubs, on the other hand, mainly exist to 'make happy noises', and one of the ways they have to do that, is to return data from dependencies, when return data is required.