3 ms·

so what's your approach to ensuring the software you deploy is correct?

by keithnz 10y ago

pka 10y ago
Having a good type system would be a good start :)
- koder2016 10y ago
  Don't upset the scripters ;).
- keithnz 10y ago
  I agree :)
YZF 10y ago
As someone I know likes to say, write better code? It's a given that software needs to be tested. The processes around that are a classical "it depends" question. Most likely any software you deploy will never be "correct" (whatever that means). The quality of that software depends on many variables and it's up to you to try and tweak them while optimizing for things like cost, time etc. Whether it's worthwhile to write the tests ahead of time or after the fact or to do them manually or automatically or any other permutation is just not a question that can be answered in a way that applies to all situations.
- st3v3r 10y ago
  That's like saying, if you're poor, you should buy more money.
- gozur88 10y ago
  >It's a given that software needs to be tested. The processes around that are a classical "it depends" question. Yes. What you need to do to ensure the correctness of flight software for a jet fighter is entirely different than what you need to do to ensure the correctness of an internal tool at your company that automates a task for which you already have a manual process.
GrinningFool 10y ago
How does TDD prove its correctness? TDD suffers from the same limitations as the code - it generally only covers what you could think of. It's a powerful tool, but I think any belief that sufficient test coverage (in most common cases) actively proves correctness is misguided. In the general case, even full test coverage proves only that you've tested for the conditions you expect - but does nothing to verify the correctness of behavior in conditions you didn't expect.[1] To me the benefits of TDD are three-fold: 1. It makes you think of what you're building in more detail before you build it. 2. The methodology puts heavy emphasis on short test-code cycles. 3. (Applies to any methodology that emphasizes coverage) You end up with an acceptable-to-great regression suite[1], and anecdotally it seems people do a better job of at least ensuring tests exist when required to by the methodology. All of these things are equally possible without TDD. Short iterative cycles and additional forethought are perfectly possible without TDD, but they do require more discipline - it is harder to remember to stop after completing a small set of changes without a forcing mechanism. [1] rust is a possible exception here, still wrapping my head around it. [2] the value of this regression suite varies greatly from project to project. A hint that tests are of low value /potentially high cost can be seen when you're finding that minor internal changes either break a large number of tests or reduce coverage to noticeable degree. Particularly in absence of functional changes.
- cjwoodall 10y ago
  Testing validates that the program is correct according to some base of assumptions. You run into this a whole lot in embedded systems, where mocking hardware is difficult. You can't feasibly unit test against real hardware (most of the time), so instead you unit test against your assumption of what the hardware does and verify you respond according to requirements. Has the benefit of proving correctness of your assumptions, which makes it easier to debug once you insert it in system and things inevitably are not 100% right. It gives you a way to reason about what your code does, what might be different, and then allows you to revise your assumptions and get your new solution in place and tested without the often long wait times to do manual testing on deeply embedded hardware. Sometimes traditional TDD is the answer, sometimes simulations are the answer, and sometimes you need to just get out of your chair and test it out. It is a tool!
- 10y ago
GFK_of_xmaspast 10y ago
"TDD" is not the same thing as "having unit and integration tests".
taneq 10y ago
You can use automated unit and integration testing without doing "TDD". The overhead isn't even particularly high; you have to test any piece of code you write anyway, so you might as well put in a tiny bit of extra effort and have unit testing.

so what's your approach to ensuring the software you deploy is correct?

by keithnz 10y ago

so what's your approach to ensuring the software you deploy is correct?

pka 10y ago

Having a good type system would be a good start :)

koder2016 10y ago
Don't upset the scripters ;).
keithnz 10y ago
I agree :)

YZF 10y ago

As someone I know likes to say, write better code? It's a given that software needs to be tested. The processes around that are a classical "it depends" question. Most likely any software you deploy will never be "correct" (whatever that means). The quality of that software depends on many variables and it's up to you to try and tweak them while optimizing for things like cost, time etc. Whether it's worthwhile to write the tests ahead of time or after the fact or to do them manually or automatically or any other permutation is just not a question that can be answered in a way that applies to all situations.

st3v3r 10y ago
That's like saying, if you're poor, you should buy more money.
gozur88 10y ago
>It's a given that software needs to be tested. The processes around that are a classical "it depends" question. Yes. What you need to do to ensure the correctness of flight software for a jet fighter is entirely different than what you need to do to ensure the correctness of an internal tool at your company that automates a task for which you already have a manual process.

GrinningFool 10y ago

How does TDD prove its correctness? TDD suffers from the same limitations as the code - it generally only covers what you could think of. It's a powerful tool, but I think any belief that sufficient test coverage (in most common cases) actively proves correctness is misguided. In the general case, even full test coverage proves only that you've tested for the conditions you expect - but does nothing to verify the correctness of behavior in conditions you didn't expect.[1] To me the benefits of TDD are three-fold: 1. It makes you think of what you're building in more detail before you build it. 2. The methodology puts heavy emphasis on short test-code cycles. 3. (Applies to any methodology that emphasizes coverage) You end up with an acceptable-to-great regression suite[1], and anecdotally it seems people do a better job of at least ensuring tests exist when required to by the methodology. All of these things are equally possible without TDD. Short iterative cycles and additional forethought are perfectly possible without TDD, but they do require more discipline - it is harder to remember to stop after completing a small set of changes without a forcing mechanism. [1] rust is a possible exception here, still wrapping my head around it. [2] the value of this regression suite varies greatly from project to project. A hint that tests are of low value /potentially high cost can be seen when you're finding that minor internal changes either break a large number of tests or reduce coverage to noticeable degree. Particularly in absence of functional changes.

cjwoodall 10y ago
Testing validates that the program is correct according to some base of assumptions. You run into this a whole lot in embedded systems, where mocking hardware is difficult. You can't feasibly unit test against real hardware (most of the time), so instead you unit test against your assumption of what the hardware does and verify you respond according to requirements. Has the benefit of proving correctness of your assumptions, which makes it easier to debug once you insert it in system and things inevitably are not 100% right. It gives you a way to reason about what your code does, what might be different, and then allows you to revise your assumptions and get your new solution in place and tested without the often long wait times to do manual testing on deeply embedded hardware. Sometimes traditional TDD is the answer, sometimes simulations are the answer, and sometimes you need to just get out of your chair and test it out. It is a tool!
10y ago

GFK_of_xmaspast 10y ago

"TDD" is not the same thing as "having unit and integration tests".

taneq 10y ago

You can use automated unit and integration testing without doing "TDD". The overhead isn't even particularly high; you have to test any piece of code you write anyway, so you might as well put in a tiny bit of extra effort and have unit testing.