No, a function can be long but have a low cyclomatic complexity score [1] (being a list of do_this(), do_that(), do_somethingelse(), etc) while a short function can have a higher cyclomatic complexity score (lots of fiddly logic).
You could deliberately do that. But most of the time length and complexity correlate. More importantly, when you're splitting up functions to make them testable, you're very much reducing complexity and length in tandem.
Splitting up functions just to make them testable is like a code smell, in my experience. It has correlated highly with cultish adherence to testing for the sake of testing rather than to achieve an engineering or quality goal.
It might be reducing "cyclomatic complexity" but not necessarily overall complexity. Often the opposite is true: reduced locality imposes its own costs in maintenance and efficiency for example.
I don't think that makes sense, if I had a longish method or a task that could be decomposed into smaller pieces to clearly identify what's happening I would prefer to break it up and test those pieces if it made sense. Obviously this depends on how you do it. DDD talks about this in terms of services and such which might be what your long function really is. In which case you _do_ have to test this large chunk of logic.
It isn't harder to test, necessarily. It's harder to unit-test. The distinction is important. Perhaps a single test that TDD people might call an "integration test" suffices for that function. Often it does, in fact.
An integration test isn't a test for a function. Its a test of the system as a whole. On a per function level, more code in a function makes it harder to test, whether you are unit testing it or somehow manually testing it.
