Let's say I have a relational data model:
InputContainer 1-* Input 1-1? InputInfo 1-1 Link 1-1 OutputInfo 1-1? Output 1-* OutputContainer
What exactly are Input, Output doesn't matter, what's important is that for every Input there may be zero or one InputInfo, the same goes for every Output. Inputs and Outputs are grouped in containers - they may be up to say 1024 Inputs per container. Link is used to connect Input to Output, this connection is not always present (when it is then InputInfo and OutputInfo are present too).
This is a legacy model that I cannot change. Now to the problem. I have a class that for given InputContainer (and it's Inputs) should find all linked Outputs and update one of their fields. Then for these updated Outputs I need to find all OutputContainers and update some properties of the container (too preserve invariant's in containers, this will require loading all container Outputs). Properties to update are simple, you may assume that I just change some int
value in Output and that OutputContainer contains field that should be sum of these int
s. When I implemented domain service that does exactly that, it basically is all about reading data from DB and saving data to DB. All queries are encapsulated in repository methods.
How I can effectively test this class, when I try to write unit-tests it turns out that there is plenty of data to mock/stub and since most logic is in queries I still need some integration tests. Should I in this case relay only on integration tests - but that still doesn't solve problem with huge amount of data that needs to be set up to test this class, and creating this data in test makes test unreadable.
Yikes, this question turned out longer that I expected; To sum up how to unit-test domain services that implement "data intensive" logic?
Aucun commentaire:
Enregistrer un commentaire