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.

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 is as fast or faster as a regular string match when there is a direct 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 matches 100% 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.

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.

Unit tests are supposed to enable you to safely refactor or rewrite code, because the tests guarantees you don't break anything. But if the test is coupled to the implementation, you will have to modify the test at the same time as the code, which means you could easily introduce errors, and the whole benefit of unit tests is lost.

In short, unit tests should verify that the unit fulfills its requirements, but not how it does this, which is is the 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.

In your case, the expected behavior is the specification of the match. Whether this is implemented in one or more methods is an implementation detail. Imagine you find a better fuzzy matching algorithm which have the property that is as fast as a regular string match when there is a direct 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!

But I understand you want to ensure the performance optimization is not lost. There are two possibilities:

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

In case the benefit 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 not just whether certain methods are called or not.

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.

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 is as fast or faster as a regular string match when there is a direct 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 matches 100% 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.