4 ms·

NO TESTING until after you’ve decided your program is correct. Why? What is there to be gained by asking programmers to abide by such an unnatural constraint?

NO TESTING until after you’ve decided your program is correct. Why? What is there to be gained by asking programmers to abide by such an unnatural constraint? I would never "decide my program is correct" without having tested at least bits and pieces of it in the REPL.

stingraycharles 17y ago
Because it forces one to think things through instead of using trial and error.
- derwiki 17y ago
  Isn't one of the advantages to programming over other disciplines that we can create unit tests that define "success" and iterate quickly until we get there?
  - DLarsen 17y ago
    Unit tests are code too. What ensures the correctness of the tests themselves? My point is simply that you can't simply defer to testing as a cop out to avoid claiming confidence in the correctness of some portion of code. There has to be some amount of code that a dev can pretty well validate simply by inspection. (I'm not saying don't test.)
- abstractbill 17y ago
  You say that as if it's a given you can only do one or the other. FWIW, I'm a pure mathematician by training - not exactly a shortage of experience in thinking things through. But I would have very low confidence in any code I had just written down, instead of building it iteratively, using a REPL.
DLarsen 17y ago
Maybe the wording used was a little unnatural. None of us write code and have no clue whether it's correct or not. We should have a certain degree of confidence. In the example given, I think it would be more realistic to ask devs to write the function (without testing) and then note how confident you are in its correctness. I have no problem with someone who is pretty sure they have bugs and can discover and fix them. But if someone is confident they have it right and they're dead wrong... now we have a problem.
- FutureNerd 17y ago
  No, there's a point to doing the unnatural thing of, "Keep working on it till you're sure you got it right."
LiveTheDream 17y ago
Because every programmer's gut reaction to binary search is "that's easy!". The no testing rule says "orly? then show me"
- abstractbill 17y ago
  every programmer's gut reaction to binary search is "that's easy!" Perhaps I'm not a programmer then. Or I'm a strange one I guess. I tend to approach every programming problem assuming the worst: This will be much harder than it seems. There will be corner-cases. I will miss some of them and do the wrong thing for other ones. I should try to enumerate every weird condition I can think of, and then throw random inputs at things to catch the stuff I missed.
  - darthpanda 17y ago
    I bet you're an experienced programmer considering the attitude. It's funny, the longer you stay in programming the more you start to truly grasp how much you don't know. But you get better knowing that. Paranoia about one's own abilities and planning accordingly creates confidence and quality. Unwarranted hubris just causes you to work weekends.
  - deleted 17y ago
    [deleted]
  - sukuriant 17y ago
    Sounds like I'm not a programmer, either. Working on the Programming Team for my school for many years taught me to consider edge-cases. And personally, there's quite frequently SOMETHING I forget when writing a binary search, and it usually ends in it infinite looping -- so, I often have to go find my stupid mistake.
- Dove 17y ago
  Binary search is easy. Unless you're going to force me to do it with a Turing machine, and all names and notes must be in pig latin, and I have to do it all while gargling lemonade. But, then, that wouldn't exactly the fault of binary search, would it? There's a reason incremental testing is normal practice. It makes you smarter.
decode 17y ago
Because trying it and failing you teaches you not to do that. Or, more generally, 90% of programmers failing the task tells us programmers are bad at programming without testing and we need to have solid testing in place when we code.
jpr 17y ago
You do realize that testing can only show the existence of bugs, not their absence or the correctness of the program?

stingraycharles 17y ago

Because it forces one to think things through instead of using trial and error.

derwiki 17y ago
Isn't one of the advantages to programming over other disciplines that we can create unit tests that define "success" and iterate quickly until we get there?
- DLarsen 17y ago
  Unit tests are code too. What ensures the correctness of the tests themselves? My point is simply that you can't simply defer to testing as a cop out to avoid claiming confidence in the correctness of some portion of code. There has to be some amount of code that a dev can pretty well validate simply by inspection. (I'm not saying don't test.)
abstractbill 17y ago
You say that as if it's a given you can only do one or the other. FWIW, I'm a pure mathematician by training - not exactly a shortage of experience in thinking things through. But I would have very low confidence in any code I had just written down, instead of building it iteratively, using a REPL.

DLarsen 17y ago

Maybe the wording used was a little unnatural. None of us write code and have no clue whether it's correct or not. We should have a certain degree of confidence. In the example given, I think it would be more realistic to ask devs to write the function (without testing) and then note how confident you are in its correctness. I have no problem with someone who is pretty sure they have bugs and can discover and fix them. But if someone is confident they have it right and they're dead wrong... now we have a problem.

FutureNerd 17y ago
No, there's a point to doing the unnatural thing of, "Keep working on it till you're sure you got it right."

LiveTheDream 17y ago

Because every programmer's gut reaction to binary search is "that's easy!". The no testing rule says "orly? then show me"

abstractbill 17y ago
every programmer's gut reaction to binary search is "that's easy!" Perhaps I'm not a programmer then. Or I'm a strange one I guess. I tend to approach every programming problem assuming the worst: This will be much harder than it seems. There will be corner-cases. I will miss some of them and do the wrong thing for other ones. I should try to enumerate every weird condition I can think of, and then throw random inputs at things to catch the stuff I missed.
- darthpanda 17y ago
  I bet you're an experienced programmer considering the attitude. It's funny, the longer you stay in programming the more you start to truly grasp how much you don't know. But you get better knowing that. Paranoia about one's own abilities and planning accordingly creates confidence and quality. Unwarranted hubris just causes you to work weekends.
- deleted 17y ago
  [deleted]
- sukuriant 17y ago
  Sounds like I'm not a programmer, either. Working on the Programming Team for my school for many years taught me to consider edge-cases. And personally, there's quite frequently SOMETHING I forget when writing a binary search, and it usually ends in it infinite looping -- so, I often have to go find my stupid mistake.
Dove 17y ago
Binary search is easy. Unless you're going to force me to do it with a Turing machine, and all names and notes must be in pig latin, and I have to do it all while gargling lemonade. But, then, that wouldn't exactly the fault of binary search, would it? There's a reason incremental testing is normal practice. It makes you smarter.

decode 17y ago

Because trying it and failing you teaches you not to do that. Or, more generally, 90% of programmers failing the task tells us programmers are bad at programming without testing and we need to have solid testing in place when we code.

jpr 17y ago

You do realize that testing can only show the existence of bugs, not their absence or the correctness of the program?