Is creating "testable code" always consistent with following the best OOP design principles?

This is perhaps too general/subjective a question for StackOverflow, but I've been dying to ask it somewhere.

Maybe it's because I'm new to the software engineering world, but it seems like the buzzwords I've been hearing the past couple years are like

• "testable code"
• "test coverage"
• "pure functions"
• "every code path in your entire application covered by a test that is a pure in-memory test -- doesn't open database connections or anything. Then we'll know that the code we deploy is guaranteed to work" (yea, right lol)

and sometimes I find this hard to reconcile with the way I want to design my application.

For example, one thing that happens often is I have a complex algorithm inside one or more private methods

private static void DoFancyAlgorithm(string first, string second)
{
   // ... 
}

and I want or need it to have test coverage.

Well, since you're not supposed to directly test private methods, I have 3 options:

• make the method accessible for test (maybe InternalsVisibleTo in C# or friend in C++)
• move the logic to a separate class whose "single responsibility" is dealing with this logic, even though from an OOP perspective I believe the logic should be confined to the class it is currently inside, and test that separate class
• leave the code as-is and spend 100+ hours figuring out to setup the scenario where I indirectly test the logic of the method. Sometimes this means creating ridiculous mock objects to inject in the class with.

So my question is:

Is creating "testable code" always consistent with the best OOP practice or is there sometimes a tradeoff?