Unit testing composition

We have a task FooTask. We are creating a Foo class, which have 1 responsibility from business loginc point of view. But it turns out, that FooTask is really complex. It consists of few steps/subtasks, which could be then represented by classes Bar/Baz responsibility. Those classes have no real sense outside Foo class, they won't be use solely. So they will probably have a package scope or something like that.

So suppose your Foo class, representing FooTask becomes:

public class Foo {
    private final Bar bar;
    private final Baz baz;

    // all-args constructor

    public ReturnType doFooTask(InputParam input) {
        final SubResult subresult = bar.doBarSubTask(input);
        return baz.doBazSubTask(subresult);
    }
}

Now, how would you test that? I see two options, but don't know which one is better:

1) test classes Bar and Baz through Foo's public API. I see one major flow with this approach: The more subojects you use to compose you object, the more test cases arrives.

2) Write complete test suites for classes Bar and Baz on their own (they are package private, so I can test them without any problem as soon as I keep proper test package hierarchy).

But then what? Should I leave my Foo class untested? Should I repeat my tests (this leads to my previous problem - lot of test cases, what is worse, copy-pasted)? Or maybe should I mock out all the dependencies and just assert, that my proper method on my mock was called while calling Foo's method?