No.

Unit tests are supposed to let you safely refactor or rewrite code by showing everything still works as it is supposed to. But if the test code is coupled to the implementation details of the unit, you will have to modify the test *at the same time* when you change the code. Which means you could easily introduce errors, and the whole benefit of unit tests is lost.

In short, unit tests should verify the requirements of the unit are fulfilled, but not care about implementation details.

This is why it is bad practice to test private methods. Private methods are supposed to be implementation details. The same goes for verifying if a private method is called or not, or in what order.

In your case, the expected behavior is some level of fuzzy matching. What algorithm is used, and whether it is implemented in one or more methods is an implementation detail. 

Imagine you find a better fuzzy matching algorithm which have the property that it is as fast or faster as a regular string match when there is an exact match. This allows you to skip the special casing of the exact match. This would be an improvement which preserved the expected behavior - but it would cause your test to fail! The test *prevent* you from improving the code.

Or you might realize that if `Forename` has an exact match but `Surname` does not, then there is no reason to perform a costly fuzzy match on `Forename` again. But preventing this will require a restructuring of the order of method calls, so most likely you test will again prevent this change, even though behavior remains correct *and* performance is improved. So the test have negative value.

But I understand you want to ensure that comparing strings which are fully equal should not be significantly slower due to the fuzzy algorithm. I see two possibilities:

 - the performance benefit for this optimization is insignificant
 - the performance benefit is significant

If it is insignificant, you should not waste time on testing it. If it is significant you should test it, but you should test the actual performance (time or processor cycles), not irrelevant implementation details.