Robert Martin on TDD proof

Transcript

1. Sequence, Selection, Iteration. Dijkstra showed that any program, regardless of how complicated it is, can be composed of these three structures. He called the technique Structured Programming. Structured Programs are provable. If something is provable it means you can reason about it. If something is not provable it means you can’t reason about it. And if you can’t reason about it, you can’t properly test it. Scientists depend on empirical data, they run experiments, and the experiments can’t prove theories true, they can only prove them false, just like tests. So those tests run by TDD , they are just as valid as experiments, and the conclusions we draw from them, they are as valid as theories. This is where Dijkstra missed it, in my opinion. He thought of software as a kind of mathematics. He wanted to build up a library of postulates and theorems and corollaries and proofs. Instead, what we have realised is that writing a program is a kind of scientific activity. We validate that activity by using experiments. We build up theories by having passing test suites. Like any science, it is an observational activity. Have scientific theories been proven correct? Of course not, we have no mathematical proof of these theories. There is no way to mathematically prove these theories correct, and yet, we still believe them. We believe them enough to bet our lives on them. The fact that we have not mathematically proven these theories correct does not mean that we don’t have sufficient proof of these theories in order to depend upon them even with our lives. That’s the kind of proof that TDD gives us. Not mathematical, formal proof, but experimental, empirical proof, the kind of proof that scientists depend upon every day. The third promise of the programmer’s oath: I will produce, with each release, a quick, sure, and repeatable proof that every element of the code is correct (works as it should). It is the promise that Dijkstra contemplated so long ago, and that led him to alter the very structure of the code that we produce, and it is the promise that has led us to the discipline of TDD . Structured programming is the result of the reasoning process of functional decomposition TDD forces you into functional decomposition you simply cannot do TDD unless you are functionally decomposing the problem. every system built with TDD is composed of functionally decomposed elements that conform to structured programming and that, together with the system that they compose are provable. And those tests are the proof. That is not quite correct. The tests created by TDD are not a formal proof, a mathematical proof like Dijkstra wanted. Indeed Dijkstra is famous for saying that tests can only prove a program wrong, and can never prove it correct. To prove that your program is correct you have to make sure that it has a structure that allows it to be provable. We are going to study one of the giants of our industry: A man who showed that it is possible to prove programs correct if you imbue them with the right structure. His name was Edsger Wybe Dijkstra https://cleancoders.com/ Edsger Wybe Dijkstra Robert Martin