7 ms·

> You would obviously test the software before it goes to the users That... is literally what unit tests do. Test the software before you give it to users. Yo

> You would obviously test the software before it goes to the users That... is literally what unit tests do. Test the software before you give it to users. You seem confused what the debate is over. Nobody is arguing against contracts. They're awesome. They're just not substitutes for unit tests (or vice versa for that matter). You guys have been arguing against unit tests, which is an absurd position to take, hence this whole debate.

mempko 2y ago
It's not absurd. Unit test are expensive and slow you down while at the same time not targeting the part of software where bugs occur. It's usually HOW functions are composed that cause bugs, not the functions themselves. Contracts rest the interaction of components while unit tests don't.
- dataflow 2y ago
  This is definitely absurd... but okay, riddle me this then. Say you're reimplementing string.indexOf(string) with your fancy new algorithm so you can deliver a nice speed boost to users. How do you do your best to minimize the chances of it blowing up on everyone without writing unit tests?
  - mempko 2y ago
    First, users don't use string.indexOf(string). Users use software that uses string.indexOf(string). Second, I would write a test that takes generates a variety of inputs to cover the domain of string.indexOf(string) and have it call the old version and the new version. I would then collect stats around the performance of each call and make sure the new implementation is faster by the threshold I meant for it to be. Since the PURPOSE OF THE REFACTOR WAS PERFORMANCE. Then I would delete the test after I'm satisfied it worked well on the target hardware, etc. Let's look at the chrome unit tests. https://chromium.googlesource.com/v8/v8/+/3.0.12.1/test/mjsunit/string-indexof-2.js https://chromium.googlesource.com/v8/v8/+/3.0.12.1/test/mjsu... This test checks one case and then does a loop over to make sure various sizes work. This is a POOR test because it doesn't cover the domain of the function and exceptional cases. This test is pointless to have and run every build. Why keep it, it does nothing useful. My point is that if you are refactoring a function, you are going to have to write a NEW TEST anyway because the purpose of a refactor is different each time. The old tests are going to be useless. This is why contracts are so useful because they will ALERT YOU when the software does something you didn't assume. Unit tests don't do this. From an information theory perspective, the old tests would not provide you with new information. If you want to make sure your refactor works like the old function, then compare the outputs of your new function with the old one over the domain of the function. Then if it's good, delete the tests because why keep them. Experience shows that users will do things to your program you did NOT expect and therefore your tests will not cover. And more likely than not, refactoring requires rewriting tests anyway so the old tests are usually always useless. Now SYSTEM tests ARE useful. Tests that wire up many components and test them are useful. But a UNIT test, which tests one function is often just a waste of time to keep.
    - dataflow 2y ago
      Honestly... I can see it's going to be genuinely exhausting for me to rebut point-by-point here, so I'll just let others read this and continue if they're interested. I really appreciate the response though, at least it explains your thought process well. I have one question for you that I feel I have to ask: have you actually practiced commercial software development on a team (say, 5+ developers on the same codebase) in this manner that you describe for a significant period of time (say, 2+ years)? and if so, do you feel the resulting software has been robust and successful?
      - mempko 2y ago
        I've been doing this style of software development for 16 years (out of 28 years programming) across various projects. If you want a small project that I wrote to look at, see henhouse https://github.com/mempko/henhouse https://github.com/mempko/henhouse. I wrote an article talking about design by contract and why it's better than TDD here https://mempko.wordpress.com/2016/08/23/the-fox-in-the-henhouse/ https://mempko.wordpress.com/2016/08/23/the-fox-in-the-henho... I've built a computer vision system that processed petabytes of data with only one or two bugs in production for any given year. At any given time we kept a bug list of zero. For the last five years I built a trading system using this same process. Again, we don't keep a bug list because if there were bugs, the system wouldn't even run. And if there is a bug we have to fix it immediately. We do have tests, but they are system tests. The worst bug we had that took too long to catch was in a part of the system that DIDN'T use contracts. Design by Contract is a secret weapon people don't seem to know about. Also see https://github.com/mempko/firestr https://github.com/mempko/firestr, which I used Design by Contract extensively. It's a GUI program so the user can do crazy things. Learn Design by Contract. Do system testing. Do exploratory testing. Do fuzz testing. Keep a bug list of zero. Don't waste time on unit testing. If you are looking for popular software built using Design by Contract to various degree. See SQLite (uses assertions heavily), .NET framework from Microsoft, Many of the C++ Boost libraries, Parts of Rust, Parts of Qt. The Vala programming language, Ada GNAT... and many others. Here is a research paper from Microsoft that shows the advantage of contracts and code quality. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2006-54.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
- sham1 2y ago
  To be fair, "functions themselves" seldom form a valid unit, so in practice you'd end up having to test the composition of said functions.

mempko 2y ago

It's not absurd. Unit test are expensive and slow you down while at the same time not targeting the part of software where bugs occur. It's usually HOW functions are composed that cause bugs, not the functions themselves. Contracts rest the interaction of components while unit tests don't.

dataflow 2y ago
This is definitely absurd... but okay, riddle me this then. Say you're reimplementing string.indexOf(string) with your fancy new algorithm so you can deliver a nice speed boost to users. How do you do your best to minimize the chances of it blowing up on everyone without writing unit tests?
- mempko 2y ago
  First, users don't use string.indexOf(string). Users use software that uses string.indexOf(string). Second, I would write a test that takes generates a variety of inputs to cover the domain of string.indexOf(string) and have it call the old version and the new version. I would then collect stats around the performance of each call and make sure the new implementation is faster by the threshold I meant for it to be. Since the PURPOSE OF THE REFACTOR WAS PERFORMANCE. Then I would delete the test after I'm satisfied it worked well on the target hardware, etc. Let's look at the chrome unit tests. https://chromium.googlesource.com/v8/v8/+/3.0.12.1/test/mjsunit/string-indexof-2.js https://chromium.googlesource.com/v8/v8/+/3.0.12.1/test/mjsu... This test checks one case and then does a loop over to make sure various sizes work. This is a POOR test because it doesn't cover the domain of the function and exceptional cases. This test is pointless to have and run every build. Why keep it, it does nothing useful. My point is that if you are refactoring a function, you are going to have to write a NEW TEST anyway because the purpose of a refactor is different each time. The old tests are going to be useless. This is why contracts are so useful because they will ALERT YOU when the software does something you didn't assume. Unit tests don't do this. From an information theory perspective, the old tests would not provide you with new information. If you want to make sure your refactor works like the old function, then compare the outputs of your new function with the old one over the domain of the function. Then if it's good, delete the tests because why keep them. Experience shows that users will do things to your program you did NOT expect and therefore your tests will not cover. And more likely than not, refactoring requires rewriting tests anyway so the old tests are usually always useless. Now SYSTEM tests ARE useful. Tests that wire up many components and test them are useful. But a UNIT test, which tests one function is often just a waste of time to keep.
  - dataflow 2y ago
    Honestly... I can see it's going to be genuinely exhausting for me to rebut point-by-point here, so I'll just let others read this and continue if they're interested. I really appreciate the response though, at least it explains your thought process well. I have one question for you that I feel I have to ask: have you actually practiced commercial software development on a team (say, 5+ developers on the same codebase) in this manner that you describe for a significant period of time (say, 2+ years)? and if so, do you feel the resulting software has been robust and successful?
    - mempko 2y ago
      I've been doing this style of software development for 16 years (out of 28 years programming) across various projects. If you want a small project that I wrote to look at, see henhouse https://github.com/mempko/henhouse https://github.com/mempko/henhouse. I wrote an article talking about design by contract and why it's better than TDD here https://mempko.wordpress.com/2016/08/23/the-fox-in-the-henhouse/ https://mempko.wordpress.com/2016/08/23/the-fox-in-the-henho... I've built a computer vision system that processed petabytes of data with only one or two bugs in production for any given year. At any given time we kept a bug list of zero. For the last five years I built a trading system using this same process. Again, we don't keep a bug list because if there were bugs, the system wouldn't even run. And if there is a bug we have to fix it immediately. We do have tests, but they are system tests. The worst bug we had that took too long to catch was in a part of the system that DIDN'T use contracts. Design by Contract is a secret weapon people don't seem to know about. Also see https://github.com/mempko/firestr https://github.com/mempko/firestr, which I used Design by Contract extensively. It's a GUI program so the user can do crazy things. Learn Design by Contract. Do system testing. Do exploratory testing. Do fuzz testing. Keep a bug list of zero. Don't waste time on unit testing. If you are looking for popular software built using Design by Contract to various degree. See SQLite (uses assertions heavily), .NET framework from Microsoft, Many of the C++ Boost libraries, Parts of Rust, Parts of Qt. The Vala programming language, Ada GNAT... and many others. Here is a research paper from Microsoft that shows the advantage of contracts and code quality. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2006-54.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
sham1 2y ago
To be fair, "functions themselves" seldom form a valid unit, so in practice you'd end up having to test the composition of said functions.