How to test implementation details when there are multiple ways of implementing the algorithm, without reading the code? I want to make sure that the code that the written code is precisely doing what it is expected to do.

For example, if I want to search in an array particularly using linear search, I don't want binary search to pass the test. 
Unit test to test the method "search" would pass irrespective of the implementation which is not what I want.
(I understand that binary search won't work if the data is unsorted, but lets say the data is sorted and I still want to make sure that it is a linear search and not the binary. In this case, I know that for sufficiently large input, BS would be way quicker than LS, but I want a generic answer where there might not be considerable difference in performance.)

Is there a way to achieve this?

An idea comes to my mind -
Divide the method in extremely small submethods and make sure that all the submethods are implemented correctly and are used in main method. However this is not desirable, this might not be feasible always.
To find out if it is e.g. doing binary search (or using hashing, or whatever) inside, you have to look at what it is doing. No way around it.

Why would you insist on a particular algorithm? The whole point of modularity (and thus of much of modern programming languages and techniques) is to be able to hide such irrelevant details, and have users depend only on observable behaviour (so you can go back tomorrow and replace a simple, inefficient algorithm by a complex, efficient one, and noone is the wiser).