4 ms·
> String to float conversion had a table missing four values. This caused an array access overflow which resulted in imprecise values in some cases. I've once
by nasretdinov 2y ago
> String to float conversion had a table missing four values. This caused an array access overflow which resulted in imprecise values in some cases.
I've once wrote a function to parse the date format from log files that Go doesn't natively support, and forgot to add November. I quit that job in April, so I never saw any issues. However when 1st of November came my ex-colleagues saw no logs for this day, and when they found out the reason they created a hash tag #nolognovember which you can probably find somewhere to this day :)
- lionkor 2y agoWho needs unit tests when you have "squints lgtm"
- Joker_vD 2y agoPfft, you know how tests for functions like this: func MonthToString(month int) string { switch month { case 1: return "January" case 2: return "February" ... case 10: return "October" case 12: return "December" default: panic(fmt.Errorf("invalid month number: %d", month)) } } are usually written? You take the switch's body, shove it into the test function, and then replace "case/return" with regexp to "assert.Equal" or something: func TestMonthToString(t *testing.T) { assert.Equal(t, "January", MonthToString(1)) assert.Equal(t, "February", MonthToString(2)) ... assert.Equal(t, "October", MonthToString(10)) assert.Equal(t, "December", MonthToString(12)) assert.PanicsWithError(t, "invalid month number: 13", func() { MonthToString(13) }) } Look ma, we got that sweet 100% code coverage!
- BobbyTables2 2y agoI feel attacked! (:>
- nasretdinov 2y agoNice nick name. What happened to the first one?
- BobbyTables3 2y agoIt got dropped.
- nasretdinov 2y agoAgain??
- gus_massa 2y agoThe solution is to add integration testing, for (i=1, i<13, i++) { assert.Equal(t, i, StringToMonth(MonthToString(i))) } the reverse composition is harder to test.
- debugnik 2y agoDid you mean property testing?
- wavemode 2y agoThis is kind of bug unit tests don't catch. The only way to exhaustively test that you're handling every possible input, is to loop over every possible input (which may tend to infinity). Therein lies the importance of runtime assertions (so we can sanity check that parsing actually succeeded rather than silently failing) and monitoring (so we can sanity check that, for example, we don't ever go 24 hours without receiving data from the parsing job).
- kccqzy 2y ago> to loop over every possible input (which may tend to infinity). This attitude is defeatist. The success of property based testing (see QuichCheck in Haskell or Hypothesis in Python) especially when combined with fuzzing shows that instead of looping over every possible input, looping over thousands of inputs tend to be good enough in practice to catch bugs. Throwing infinity as a cop out is a lazy opinion held by people who don't understand infinity, or rather, the concept of infinity that's countable. Everything we model on a computer is countably infinite. When we have multiple of such countable infinite sets, the standard dovetail constructions guarantees that their union will be countable. Their Cartesian product will also be countable. You can always obtain an interesting prefix of such an infinite set for testing purposes.
- wavemode 2y agoYour tone implies to me that you are under the impression that I'm suggesting one should not test their software. Nothing could be further from the truth. What I'm saying is that it's foolish not to take any measures at runtime to validate that the system is behaving correctly. Who's to say that the logs themselves are even formatted correctly? Your software could be perfectly bug-free and you'd still have problems without knowing it, due to bugs in some other person's software. That's the point you're missing - no matter how many edge cases you account for, there's always another edge case.
- kccqzy 2y agoOh no not at all. I didn't imply that you are suggesting one shouldn't test their software. Instead, I believe you have an overly narrow view of what tests can accomplish. I didn't say anything about measures at runtime to validate things. That's complementary to good tests.
- nasretdinov 2y agoWell I guess you can have a unit test that checks that there are 12 entries :). Repeating the same list probably wouldn't have found an issue unfortunately
- bad_username 2y ago> when 1st of November came my ex-colleagues saw no logs for this day Faced with this symptom I would bet there was a "No" in a yaml somewhere :-)