TL;DR
Who tests what criteria for epics?
Epics and themes aren't generally testable, so the answer is really "no one." Instead, the entire Scrum Team must decompose these too-large items during Backlog Refinement or Sprint Planning until they are stories that contain testable criteria that can be measured.
The entire Scrum Team, which explicitly includes the Product Owner, must collaborate on defining actionable user stories that are testable and demonstrable. Your current process does not encourage sufficient collaboration to make this happen.
In addition, your current process causes the team to miss out on opportunities to collaborate with the Product Owner to negotiate implementation details that add value, reduce project costs, or lead to increased sustainability. While the Product Owner shouldn't have to care about code-level details, understanding the trade-offs involved in different implementations can help the whole team to ensure that the right thing is built, and that opportunities to build a potentially-shippable increment are increased through open discussions about Minimum Viable Features and YAGNI principles.
Epics and themes should never, ever make it off the Product Backlog and into the Sprint Backlog. Doing so is a very strong "project smell" that indicates a fundamental problem with the implementation of the team's Scrum process.
Tasks vs. Dependent Stories
Stories
Stories and tasks are two different things. A user story has a format that's expected to act as a placeholder that defines a feature, a point of view representing the beneficiary of the feature, and a context. Variations of the Connextra format is what people think of most often:
As a [role or "value consumer"],
I want [feature or functionality]
so that [benefit within some context].
A story is a conversational placeholder to enable collaboration, and isn't intended as a full-fledged specification. Stories are generally estimated in story points (e.g. modified Fibonacci sequence, tee-shirt sizes, etc.).
Stories generally live on the Product Backlog, because while they adhere to the INVEST mnemonic they represent value to the project and potentially-shippable features.
Tasks
On the other hand, a task is a checklist item that helps them team track their progress towards story completion. A story should have tasks, but a story should (as a rule of thumb) not have dependent stories.
Tasks often live on the Sprint Backlog, rather than the Product Backlog, because they are really implementation details or technical milestones rather than stories that should strictly adhere to the INVEST critiera. Nevertheless, they should be small and testable, so there is certainly a bit of overlap.
Tasks can be story-pointed, but are often estimated in ideal hours rather than levels of effort. For example, a story like:
As a banking customer
I want to be able to use any ATM without fees
so that I have ready access to my money at any location.
should be broken down into discrete, measurable tasks during Sprint Planning. The tasks for this story, whether they are on the back of a story card, items on the Sprint Backlog, rows on a spreadsheet, or contained on their own index cards, might look like this:
- ☑ Add a database column to track ATM network membership. (2 hours)
- ☑ Add a database column to track fees associated with foreign-network ATM withdrawals. (16 hours)
- ☐ Add model callbacks to reimburse customers for ATM fees attributable to withdrawals at foreign ATMs. (8 hours)
Tasks can be added, deleted, or modified by the team throughout the Sprint as things are learned, or as dependencies or implementation details are discovered. The Sprint Backlog belongs to the Development Team, not the Product Owner, so the contents of the team's backlog reflects the work that the Development Team needs to do to implement the user story from the Product Backlog.
Collaboration
While the Product Backlog belongs to the Product Owner, and the Sprint Backlog belongs to the team, it is nevertheless useful to ensure that both artifacts are visible to everyone in the organization in order to foster collaboration.
A Product Owner who can't see the level of effort or hours involved in story-related tasks has insufficient visibility into the real costs of a given story, and the team loses out on valuable opportunities to collaborate on implementation details that are negotiable. For example, during a Sprint it may turn out that the Product Owner doesn't all fees for all banks covered; the 80/20 rule means that perhaps the team can concentrate on hard-coding values for three local banks that generate the most complaints, rather than having to engineer a more flexible solution that would apply to all banks everywhere.
Unit/Feature Testing and Sprint Review Demonstrations
Epics aren't testable or (generally) demonstrable. Neither are themes. That makes them unsuitable for Sprints; they should only be used for long-range planning, and decomposed as needed during Backlog Refinement or Sprint Planning.
All stories that adhere to the INVEST criteria are inherently testable. In my personal experience, stories should generally be driven by feature or integration tests, and tasks should be driven by unit tests. There are certainly all kinds of caveats and exceptions to this rule of thumb, but following this advice helps in many ways, including:
- Feature tests (such as automated browser testing) show the feature from a user-visible point of view, and may even stand in for user acceptance testing in many situations.
- Feature tests build trust with stakeholders, and often demonstrate that the Right Thing™ was built.
- Unit tests are for the Development Team, and help drive design and prevent regressions. They are generally uninteresting as Sprint Review demonstrations, but are the most important items from a sustainable development point of view.
This style splitting TDD and ATDD along the lines of features vs. tasks helps maintain the testing pyramid, with a few slow high-level tests supported by a base layer of blazingly-fast unit tests. For example:

As always, there will be exceptions and caveats, but as rules of thumb I have found the foregoing to be reasonably solid practices. YMMV.