Before answering such a question, you need to decide what you actually want to achieve.
You write code. You hope it fulfils its contract (in other words, it does what it is supposed to do. Writing down what it is supposed to do is a giant step forward for some people).
To be reasonably convinced that the code does what it is supposed to do, you either stare at it long enough, or you write test code that tests enough cases to convince you "if the code passes all these tests then it is correct".
Often you are only interested in the publicly defined interface of some code. If I use your library, I don't care how you made it work correctly, only that it does work correctly. I verify that your library is correct by performing unit tests.
But you are creating the library. Getting it to work correctly can be difficult to achieve. Let's say I only care about the library doing operation X correctly, so I have a unit test for X. You, the developer responsible to create the library, implement X by combining steps A, B and C, which are each totally nontrivial. To get your library working you add tests to verify that A, B and C each work correctly. You want these tests. Saying "you shouldn't have unit tests for private methods" is quite pointless. You want tests for these private methods. Maybe someone tells you that unit testing private methods is wrong. But that only means you might not call them "unit tests" but "private tests" or whatever you like to call them.
The Swift language solves the problem that you don't want to expose A, B, C as public methods just because you want to test it by giving functions an attribute "testable". The compiler allows private testable methods to be called from unit tests, but not from non-test code.