Sometimes mocking, even to check error paths, isn't a lot of work. It depends.

A lot of times designing your interfaces to support mock objects more easily improves them in other ways; if you pass in a file object instead of a filename, for example, not only does it become easier to pass in a mock object that raises an error, but it also becomes easier to pass in a GzipFile object or an HTTPResponse object, and presto, your function now handles compressed data and data stored on a web server.

Also, though, monkeypatching stuff in tests isn't hard in dynamic languages. Here's an example from https://echohack.medium.com/python-unit-testing-injecting-ex...:

    with patch.object(requests, "get") as get_mock:
        with nose.tools.assert_raises(socket.error):
            get_mock.side_effect = socket.error
            inject_exception.call_api("http://example.com")

Depends on how you write your code.

If your functions have lots of hidden dependencies and side-effects, it’s hard to test.

If you split concerns properly and keep your glue/IO code separated from the decision-making/business-rules/logic, mocking is quite trivial, and there are advantages other than just testability.

Check out this talk to see examples of that in action: https://www.destroyallsoftware.com/talks/boundaries