4 ms·

>I refactored the code from untested and untestable, to testable with 40% test coverage. This tells me you think "coverage" is a good metric, which also tells

>I refactored the code from untested and untestable, to testable with 40% test coverage. This tells me you think "coverage" is a good metric, which also tells me you're you're not covering a whole lot of cases (edge or not) where the "untested code" functioned as it should. You're asking to replace something which has potentially some known issues, with something that has a potentially unlimited amount of unknown issues. And the more experienced person at your job refused? What a tyrant!

poutrathor 7y ago
I strongly disagree. The said refactoring was probably not a huge task since he is reporting it done. Larger tasks are most often planned and monitored. Splitting some class and decoupling some resources + adding the testing framework and implementing a first batch of tests. Of course it might have introduced few regressions. But > has potentially some known issues Read again that. Exactly, none knows how many bugs there are, only how many were found so far. Bug tracking is often lacking, behind schedule, wont fix, etc. On the contrary modern code analyse tools are frightening good at spotting untested conditions every where (sonarcube comes to my mind). Much better and much reliable than human developer and human tester. Sonarcube does not care if the case can not happen because user interface does not allow the input. The bug is here, and the bug is spotted. The more experienced person is plain wrong : more tests is better. It's not panacea yet, but it's better.
- inertiatic 7y ago
  function int untested_sum(int a, int b) { return a + b; } function int tested_sum(int a, int b) { return a * b; } function void test_providing_total_coverage() { assertEqual(tested_sum(2, 2), 4, 'Expected sum to be 4!'); }
  - Doxin 7y ago
    Which is why I'm a big fan of testing tools like hypothesis: from hypothesis import given, assume from hypothesis.strategies import floats from math import isnan, isfinite def tested_sum(a, b): return a * b @given(a=floats(), b=floats()) def test_sum(a, b): assume(not isnan(a)) assume(not isnan(b)) assume(isfinite(a) or isfinite(b)) assert tested_sum(a, b) == a + b Running that test gives Falsifying example: test_sum(a=0.0, b=1.0) Note how it also forces me to put a bunch of assumptions in there explicitly, hypothesis is very good at finding weird edge cases. For this example I don't really care that it goes wrong when NaN gets involved, but if I did I discover through testing that that case even exists.

poutrathor 7y ago

I strongly disagree. The said refactoring was probably not a huge task since he is reporting it done. Larger tasks are most often planned and monitored. Splitting some class and decoupling some resources + adding the testing framework and implementing a first batch of tests. Of course it might have introduced few regressions. But > has potentially some known issues Read again that. Exactly, none knows how many bugs there are, only how many were found so far. Bug tracking is often lacking, behind schedule, wont fix, etc. On the contrary modern code analyse tools are frightening good at spotting untested conditions every where (sonarcube comes to my mind). Much better and much reliable than human developer and human tester. Sonarcube does not care if the case can not happen because user interface does not allow the input. The bug is here, and the bug is spotted. The more experienced person is plain wrong : more tests is better. It's not panacea yet, but it's better.

inertiatic 7y ago
function int untested_sum(int a, int b) { return a + b; } function int tested_sum(int a, int b) { return a * b; } function void test_providing_total_coverage() { assertEqual(tested_sum(2, 2), 4, 'Expected sum to be 4!'); }
- Doxin 7y ago
  Which is why I'm a big fan of testing tools like hypothesis: from hypothesis import given, assume from hypothesis.strategies import floats from math import isnan, isfinite def tested_sum(a, b): return a * b @given(a=floats(), b=floats()) def test_sum(a, b): assume(not isnan(a)) assume(not isnan(b)) assume(isfinite(a) or isfinite(b)) assert tested_sum(a, b) == a + b Running that test gives Falsifying example: test_sum(a=0.0, b=1.0) Note how it also forces me to put a bunch of assumptions in there explicitly, hypothesis is very good at finding weird edge cases. For this example I don't really care that it goes wrong when NaN gets involved, but if I did I discover through testing that that case even exists.