Depends on how you set it up. The sandbox is checked out and in where you or some code owned by you calls the APIs to do so. You can do both: Sandbox per generated value(s) or sandbox for the whole test.
I’d also add a completely different angle here. It sounds like you have a bunch of business logic, which at the end should result in an appropriate selection of records. You generally cannot really test Ecto.Query structs, as their content is mostly private API. So most often we default to executing the query as well to test the query.
Another option would be separating the “business logic to build up query details” from “turning query details into Ecto.Querys”. You can use a custom struct to aggregate all the information you need to build the final query. That struct can be fully (unit) testable with non-private fields. Also implement the Ecto.Queryable protocol and you can use that custom struct wherever Ecto.Queryable is accepted. The protocol implementation can then be a simpler (not as complex to test) implementation of turning the data in your struct into an Ecto.Query.
