This method seems a bit obvious to me. Of course large units should be divided into smaller parts that can be tested and of course you should test ervery component. About 15 years ago I attended a course: 'Software Engineering' where I learned to do that, so nothing really new here.

The danger of this method, or this particular (re)introduction of it, lies in the fact that the bigger scope is neglected. Most units are part of one or more bigger parts. If you work the way that is presented here, you easily loose the big picture and the focus on the final goals with it.

Those who do keep the bigger picture in mind will recognize that reusability and maintainability is not served by this method, because the focus is too narrow: on specific results for specific situations. In my opinion that can lead to systems with large amounts of small, specific components. A new function? A new component. After time nobody knows what component serves what purpose, or _if_ it still is used.

I'm not saying that the method guarantees the above, but a good method should guarantee that it will not happen.

Kind regards,

Hans van Dam