5 ms·

unit tests make sure that what you think the code does is what it is actually doing. This is great for catching corner cases that you might not always test in a

by NateDad 13y ago

unit tests make sure that what you think the code does is what it is actually doing. This is great for catching corner cases that you might not always test in a live test... or testing code that isn't yet called in live use. It also makes sure that if code changes, it's still functioning correctly. Aside from catching initial bugs, this is the biggest addition to maintainability of code. I find unit tests to be incredibly liberating. Have you ever made changes to some parts of the code, but then worried you might have broken something? With unit tests, you can be confident that your change didn't break any expected behavior.

DanWaterworth 13y ago
Excellent. You've brought up some points that come up commonly. I have some follow up questions: * To quote Dijkstra, "Testing shows the presence, not the absence of bugs", so presumably, you write tests to build confidence rather than to ensure "that what you think the code does is what it is actually doing". Is this accurate? * If so, suppose you given a code-base that contains tests. How do you determine how much confidence to place in said software? * It's very common for the space of possible inputs to be infinite, so you can't possibly test every case. How do you decide which ones are useful to write tests for? * What is your response to Rich Hickey's depiction of, what he calls, guard-rail programming ("Simple Made Easy" from around 15:30 onwards)? * Finally, how do know when you've written a good test suite? It's obviously good if it finds bugs, but how do you know that it is good without running it? Sorry to bombard you, I'm asking because I'm genuinely interested and I want write more robust software. > Have you ever made changes to some parts of the code, but then worried you might have broken something? With unit tests, you can be confident that your change didn't break any expected behavior. I must say, I've done every permutation of changing code with/without tests where my changes have broken/have not broken things. Subjectively, I can't say that there has been noticeable correlation in any direction. Perhaps that's because I'm bad at writing tests, but then, how do I write good ones?
bluntly_said 13y ago
I'm not sure I agree with you here. Tests are still only as clever as the person writing them. This means it's rarely going to catch corner cases that the developer wasn't already aware of. I think the real value of tests is exposing expected behavior to teammates, and then providing quick sanity checks against that expected behavior. The biggest thing new developers miss about testing is that most times you're not writing tests for yourself, you're writing them as a courtesy to your teammates.
- RHSeeger 13y ago
  > it's rarely going to catch corner cases that the developer wasn't already aware of Learning to recognize potential edge cases and partition inputs to check as many input categories as possible is a skill learned through experience testing.

by NateDad 13y ago

DanWaterworth 13y ago

Excellent. You've brought up some points that come up commonly. I have some follow up questions: * To quote Dijkstra, "Testing shows the presence, not the absence of bugs", so presumably, you write tests to build confidence rather than to ensure "that what you think the code does is what it is actually doing". Is this accurate? * If so, suppose you given a code-base that contains tests. How do you determine how much confidence to place in said software? * It's very common for the space of possible inputs to be infinite, so you can't possibly test every case. How do you decide which ones are useful to write tests for? * What is your response to Rich Hickey's depiction of, what he calls, guard-rail programming ("Simple Made Easy" from around 15:30 onwards)? * Finally, how do know when you've written a good test suite? It's obviously good if it finds bugs, but how do you know that it is good without running it? Sorry to bombard you, I'm asking because I'm genuinely interested and I want write more robust software. > Have you ever made changes to some parts of the code, but then worried you might have broken something? With unit tests, you can be confident that your change didn't break any expected behavior. I must say, I've done every permutation of changing code with/without tests where my changes have broken/have not broken things. Subjectively, I can't say that there has been noticeable correlation in any direction. Perhaps that's because I'm bad at writing tests, but then, how do I write good ones?

bluntly_said 13y ago

I'm not sure I agree with you here. Tests are still only as clever as the person writing them. This means it's rarely going to catch corner cases that the developer wasn't already aware of. I think the real value of tests is exposing expected behavior to teammates, and then providing quick sanity checks against that expected behavior. The biggest thing new developers miss about testing is that most times you're not writing tests for yourself, you're writing them as a courtesy to your teammates.

RHSeeger 13y ago
> it's rarely going to catch corner cases that the developer wasn't already aware of Learning to recognize potential edge cases and partition inputs to check as many input categories as possible is a skill learned through experience testing.