4 ms·

> Sorry to say but that too is your fault. First thing you're supposed to do with tests is make them fail, then make them pass They did not say they didn't do

> Sorry to say but that too is your fault. First thing you're supposed to do with tests is make them fail, then make them pass They did not say they didn't do that, you're assuming. If I were the person here, I might write a simple test with 'val1="foo"; val2="bar";' to make it fail. That would make it fail because the first byte is different, while I would think it failed because the entire value is different. You might say that I should have also tried "bar" and "baz" (which would reveal the issue), but it's infeasible to try all possible inputs. Most code is not written with exactly an excess of time to follow perfect practices every time, and so we must make tradeoffs.

aew4ytasghe5 4y ago
> They did not say they didn't do that, you're assuming. In the article, the author confirms his test was not working: > But that bug in my code ruined one month of my work. I coded without realizing tests don't work at all. OUCH! The issue is exactly what parent mentions, that OP did not let his test fail first so that they were never confident in that the test worked.
nolok 4y ago
> If I were the person here, I might write a simple test with 'val1="foo"; val2="bar";' to make it fail. That would make it fail because the first byte is different, while I would think it failed because the entire value is different. This is absolutely the wrong way to do testing and the crux of what I was getting at: you should not change a single line of code within the test itself when making them pass or fail. If you change the test itself, then it's not the same test, you have not ensured your test works, only that another test works. I'm sorry if this sounds harsh or if my phrasing is not correct, but it's important to remember this. If "testing your test" implies "making modification to the test", then you're not doing it right.
- skribanto 4y ago
  That does not address the problem described in GP at all

aew4ytasghe5 4y ago

> They did not say they didn't do that, you're assuming. In the article, the author confirms his test was not working: > But that bug in my code ruined one month of my work. I coded without realizing tests don't work at all. OUCH! The issue is exactly what parent mentions, that OP did not let his test fail first so that they were never confident in that the test worked.

nolok 4y ago

> If I were the person here, I might write a simple test with 'val1="foo"; val2="bar";' to make it fail. That would make it fail because the first byte is different, while I would think it failed because the entire value is different. This is absolutely the wrong way to do testing and the crux of what I was getting at: you should not change a single line of code within the test itself when making them pass or fail. If you change the test itself, then it's not the same test, you have not ensured your test works, only that another test works. I'm sorry if this sounds harsh or if my phrasing is not correct, but it's important to remember this. If "testing your test" implies "making modification to the test", then you're not doing it right.

skribanto 4y ago
That does not address the problem described in GP at all