I'm writing automation to black box test applications. The applications will not work with mock data, so I'll need to grab or create real data from the database using pre-written stored procedures that I have no control over. There are a lot of stored procedures. I'm also using onion architecture and DI to abstract away the CRUD-ing of my entities, be it through stored procedures or API's. Right now I have 5 layers: entities, repository interfaces, repositories, service interfaces, and services.
Lets say in my test I want to create an entity. I would use a call to an IEntityService, service.Create(entity). This service would then make use of some of the stored procedures, such as is_entity_valid, and create_entity to validate and create the entity. Again since I am merely testing, I do not control the business logic or how it is implemented, I just need to be able access the things that do implement it.
My question is this: How do I fit those stored procedures into my layers? Should they go in a repo? A service? Somewhere else?
Right now I'm thinking of dumping related sp's into classes in the repo layer, then calling them from whatever repo implementations need them. Am I on the right track?