3 ms·

You still need the tests to ensure the code is correct though. A sqrt function returning 27 for every input would be “proven correct” by static typing.

motorest 2y ago
> You still need the tests to ensure the code is correct though. You do, but not the boilerplate stuff to check that your code throws a runtime error if you pass a JSON doc to a square root function. Having runtime errors instead of compile-time ones is also a major liability. > A sqrt function returning 27 for every input would be “proven correct” by static typing. That's not what's being argued.
- deleted 2y ago
  [deleted]
- bazoom42 2y ago
  You don’t need to write boilerplate code to check that. If you use a strongly typed language like Python, you know it will throw an exception if the input is not number-like. Have you often written this type of test? What value do you feel it have given you??
  - motorest 2y ago
    > You don’t need to write boilerplate code to check that. If you use a strongly typed language like Python, you know it will throw an exception if the input is not number-like. The whole point of tests is to ensure your code doesn't trigger runtime errors caused by contract breaches. You are not describing a solution, but the actual problem you mush avoid. It's baffling how you don't realize that. > Have you often written this type of test? If you believe this is a foreign concept to you, I don't know what else there is to say. > What value do you feel it have given you?? Are you actually asking what's the value of not having your code throw exceptions because you write broken code such as passing JSON objects to square root functions?
    - bazoom42 2y ago
      Yes I would want the sqrt function to throw an exception if a JSON object was passed instead of a number. Sqrt is only defined for numbers. What would you prefer the code to do in that scenario? Of course a caller passing a json object to a sqrt function would be in error. This error should be discovered by testing the component which does that. > The whole point of tests is to ensure your code doesn't trigger runtime errors caused by contract breaches. IMHO the purpose of tests is to verify that code works correctly. Of course this implies it doesn’t throw unwanted exceptions but that is only a small part of correctness. Sqrt in not correct just because it doesnt throw an exception on a numeric input, it have to return the correct value. Testing that a component or function works correctly also automatically implies that alle necessary internal contracts are followed. The reverse is not the case.

motorest 2y ago

> You still need the tests to ensure the code is correct though. You do, but not the boilerplate stuff to check that your code throws a runtime error if you pass a JSON doc to a square root function. Having runtime errors instead of compile-time ones is also a major liability. > A sqrt function returning 27 for every input would be “proven correct” by static typing. That's not what's being argued.

deleted 2y ago
[deleted]
bazoom42 2y ago
You don’t need to write boilerplate code to check that. If you use a strongly typed language like Python, you know it will throw an exception if the input is not number-like. Have you often written this type of test? What value do you feel it have given you??
- motorest 2y ago
  > You don’t need to write boilerplate code to check that. If you use a strongly typed language like Python, you know it will throw an exception if the input is not number-like. The whole point of tests is to ensure your code doesn't trigger runtime errors caused by contract breaches. You are not describing a solution, but the actual problem you mush avoid. It's baffling how you don't realize that. > Have you often written this type of test? If you believe this is a foreign concept to you, I don't know what else there is to say. > What value do you feel it have given you?? Are you actually asking what's the value of not having your code throw exceptions because you write broken code such as passing JSON objects to square root functions?
  - bazoom42 2y ago
    Yes I would want the sqrt function to throw an exception if a JSON object was passed instead of a number. Sqrt is only defined for numbers. What would you prefer the code to do in that scenario? Of course a caller passing a json object to a sqrt function would be in error. This error should be discovered by testing the component which does that. > The whole point of tests is to ensure your code doesn't trigger runtime errors caused by contract breaches. IMHO the purpose of tests is to verify that code works correctly. Of course this implies it doesn’t throw unwanted exceptions but that is only a small part of correctness. Sqrt in not correct just because it doesnt throw an exception on a numeric input, it have to return the correct value. Testing that a component or function works correctly also automatically implies that alle necessary internal contracts are followed. The reverse is not the case.