If you've been doing TDD properly, and this is method is something that you've created during refactoring, then no - as this is already covered by tests at the appropriate level of abstraction. Refactoring is rearranging the internals without changing the functionality - and without changing tests, that act as a safety net for you. You have to make a design decision though - decide (as a team) what constitutes internals vs what is the "surface area" that should be exposed to client code and to tests. Note that both clients and tests should be unaware of those internals. Otherwise you cannot refactor. Think of the test suite as being another client for the code being tested. If at some point you find that your high level design is not quite right or that functionality needs to change, then you have to change the tests as well, or add new ones - this is expected, but it is not refactoring.
Now, if you were making something like a library that other code will use, and this function was part of its API, then you would write a test for it directly, because it's at the "surface area" in this context, but you still wouldn't have your tests coupled to the internals of that library. This consideration is (roughly) along the same lines as Doc Brown's point about reuse.
That said, sometimes, when you are dealing with a difficult-to-understand piece of logic, or a complicated, finicky algorithm, but a lot of the intricacies of how it works constitutes internal detail in that particular level of abstraction, you may want to write tests that go into that detail, to help you get a handle on the problem. You have to somehow differentiate these tests from the other ones, though, as these aren't really a part of the test suite for the application/library - these are for you. Also, since this is internal detail, the code may be volatile, and so it may change relatively frequently in ways that will require these tests to change or make them outright obsolete. So you may not even check in these tests. You may decide to delete them once you're done (yes, this is allowed). Or if this peace of code is deemed to be of particular interest (at least for the time being), you may want to decide on a way to somehow differentiate these as white-box tests and check them in anyway, with the team having a mutual understanding that these are coupled to the internals (and that they may eventually need to be changed/replaced/deleted); it may be difficult to get everyone on the same page though, and your tools & pipeline may be setup in such a way as to make this awkward to implement. Again, if this code is of particular interest, and it turns out to be long-lived, another option to consider is to place it into a separate library/package, and then write these tests in that context - giving you proper isolation and separation of concerns.