DEV Community

Discussion on: Unit Testing. Logic in Domain vs Logic in SQL

Collapse
 
bhserna profile image
Benito Serna • Edited

Hi @jadjare ,

I also think that your approach is good =)

Maybe my approach would be, to move to the place you are now in several iterations... Maybe my first implementation would be as you said to "load all the data into the domain and apply the logic there", maybe then "all grouped by product", and then something like what you have now... Moving responsibility to the database as needed.

Just in every case I would put the database behind an object to be able to call descriptive methods, like fetchAll, fetchAllGroupedByProduct, fetchCountOfLateAndPendingUnitsByProduct ... or something like that =) ... and maybe in the "unit tests" of the unit that calls this storage object, just be sure that it can handle the format of returned info using a "double" of the storage object.

I am not sure if my answer is clear enough... but I hope, it is =)

Collapse
 
jadjare profile image
jadjare

Yes, that makes sense. Sounds like we're on the same wave length.
We have a read only repository object with specific named methods along the lines you suggest.

We're writing the code in dotnetcore and using a library called Dapper for managing our requests to the database and converting the response to our strongly typed objects.