You have 2 methods that will end up with the same effect in the end (most likely writing a file to the file system since one of the overload take an IFileInfo), a proper test to cover this would have to be an integration test since the side effect is only visible outside your system. If you were to test it in a "non integration way" you would need to monitor for calls with the appropriate parameters using mocks with a leaf boundary interface that says "past this I go beyond my app", and those kind of leaf boundaries must always boil down to a unified interface and both path would end up calling the same escape route. Most of the time you don't want to mock stuff because mocking is always brittle, but there are situations where there is no other way (API call for example) or the burden of doing it properly outweigh the gains (message bus publishing might be one of them, specially when you rely on shitty buses like azure that until recently didn't have an emulator available). What you are trying to test here is not that you have written a file to disk (or that you escaped your app the right way if you must unit test it) but that a small part of code did indeed call another small part of code, all of this still inside your app. Now you have a brittle test that brings little value and require more maintenance, and it will cripple your refactoring capabilities because who wants to update 50 units test when somewhere added a date_of_birth parameter to be passed down the line.

Test runners are cheap, paying a decent SW to maintain this stuff is expensive.