Java Unit Testing - Mock all class methods to return one result

I would like to mock ALL methods on a class to return one result, instead of mocking each separately, something like:

mock(Foo.class, allMethodsWithAnyArgs).thenReturn('abc');

I'm very new to Java testing so please forgive the dumb question. This giant project has Mockito, PowerMockito, PowerMock, EasyMock, and probably other stuff so I can use anything recommended.

An extended example would be something like this, where I need to test Foo:

public class Foo {
    doSomething(){
        Bar bar = new bar();
        
        // some code

        bar.x(a);

        // some code

        bar.x(a, b, c);

        // some more code

        bar.y(...);

        // even more code

        bar.z(...);
    }
}

I need to stub all the bar calls but don't care about the return, or I want the same return, say 1 or 'ok' from all of them, etc.

UPDATE:
I agree this isn't the best code to test, here is an updated example of what I am trying to test in this case, so I need to stub MyUtil and the bar methods, these are static, so how do you suggest I refactor them? It doesn't make sense to me to put MyUtil as a required argument, and I would prefer to keep Foo as static if possible. A working test file would be super appreciated as I have been struggling with this kind of thing for a few days now.

public class Foo {
    public static Object doSomething(Long id){
        Bar bar = new Bar();
        Object obj;

        if(somecondition) {
            Long vnumber = MyUtil.getVNumber(id);
            
            obj = bar.getCurrentObj(id, vnumber);            
        } else {
            obj = bar.getPreviousObj(id);
        }
        
        bar.z(obj);
        ....
    }
}

Also, one of the points of this class was to make it a black box, I don't want the called to worry about creating instances and passing them in, or even knowing how things work, I just want to pass an ID and get a result for it. Some of the calling functions don't even HAVE access to Bar for example so I can't make it a required parameter.

Having so many methods to mock can be a sign of a class with too many responsibilities.

However, mocks are not the only test doubles. What might better suit your use case is a fake.

This would really depend on Foo being behind an interface:

interface Bar {

   String x(String s);

   String y(String s);
}

then you have your prod implementation:

class RealBar implements Bar {
   
    @Override
    String x(String s) {
        // whatever your production logic is
    }
}

and then a fake you use in the test that sits in your test source set:

class FakeBar implements Bar {

    @Override
    String x(String s) {
        return "abc";
    }
}

Because the fake works out-of-the-box, you can reuse it and you don't have to manually stub behaviors for it.

If you use constructor injection in Foo, your test will consist of passing in your fake Bar instead of the production Bar

@Before
public void setUp() {
   foo = new Foo(new FakeBar());
}

Fakes are thus the accepted way of avoiding the burden of manually stubbing.

However, if you have no alternative to stubbing every single method of a class to return the same value, this is not a common use case and unlikely to be supported by most mocking libraries. Especially when Mockito tries to be opinionated on class design in order to prevent you from writing suboptimal code.

You could manually write code that used reflection to find the declared methods and then stub the behavior. By the time you do this, may as well have performed "Extract interface" and written a fake.