> he explicitly said, that this is lame implementation and can be optimized (for example by looping until square root of the number) Was this the same video wh

> he explicitly said, that this is lame implementation and can be optimized (for example by looping until square root of the number) Was this the same video where he chastised programmers who mentioned the Sieve of Eratosthenes? Without actually explaining why that was the wrong solution? > while benchmarks are tests for performance Certainly benchmarks are useful tests. But so are edge conditions. Consider "average(i, j)". The simple solution is (i+j)/2, but if i+j overflows then the answer will be wrong. If max signed/unsigned int is allowed as an input value, or an overflow might happen in an intermediate value, then those should surely be part of the tests which drive the code. Without it, it's all too easy to have a silent integer overflow. Going back to the primes code, 2^31-1 might be seen as a performance test. Or if the code was written well in the first place, it might just be a simple bounds check. For that matter, if 'well-written unit tests ... provide a working specification of your functional code', then where's the documentation which defines the expected or at least preferred input range? Or the step to point out that the input spec is under-defined and needs clarification? > So maybe, Martin Fowler, when coining this term, meant something different? Funny thing that. If you look around, you'll see that most people quote his example almost verbatim. In general they like to replace user code with system code. This makes me think that most people either think it's trivially obvious, or haven't really thought about it. (I think few people really do algorithm development, so neither one would surprise me.) In "Refactoring: Improving the Design of Existing Code" p. 139, at https://books.google.com/books?id=HmrDHwgkbPsC&pg=PA139&lpg=PA139&dq=%22Substitute+Algorithm%22&source=bl&ots=y57hwpM6_X&sig=gx3IPpj74SWg4F6xjSf3VnKLxBE&hl=sv&sa=X&ved=0ahUKEwiExJrKwOTKAhWBwHIKHR4OCM44ChDoAQgeMAE#v=onepage&q=%22Substitute%20Algorithm%22&f=false https://books.google.com/books?id=HmrDHwgkbPsC&pg=PA139&lpg=... , you'll that Fowler says to apply "Substitute Algorithm" only if the newer algorithm is clearer. He also says that if it compiles and passes all of the existing tests, then your done. My complaint is that even a clearer algorithm can have different edge cases, so you have to analyze the code and perhaps add new tests before you are done. > is actually a smell to my knowledge My statement was based on reviewing Martin's FitNesse code some six years ago. I can no longer recall if my memory is accurate, and withdraw my comment. > from one year to another, someone always coins "Unit tests are dead, long live Integration tests"; another year and someone says: "Integration tests are dead, long live Unit tests". It flips over and over again. Coplien doesn't say that. While he believes that most unit tests are a waste, he encourages unit tests for "key algorithms for which there is a broad, formal, independent oracle of correctness, and for which there is ascribable business value". Sorting definitely falls into that category. He also points out that maintaining unit tests which are also covered by your functional tests is a waste of maintenance time, and says to get rid of those unit tests. I've always found it hard to work in an airplane, and don't travel anywhere often enough to need to worry about it. :) Thanks also for your compliment. Best of wishes.