3 ms·

> You should very rarely have to change tests when you refactor code. I'm going to say this is poor, if not outright dangerous, advice. I'd argue the opposite:

by luord 9y ago

> You should very rarely have to change tests when you refactor code. I'm going to say this is poor, if not outright dangerous, advice. I'd argue the opposite: every time the code changes, it would be great if a test somewhere broke. Hell, if the tests originally were for a gigantic class with a ton of mocks but the code changed so there was lower coupling and the dependencies were injectable or separated in different modules, the tests should be changed. > even a strongly typed language should have tests Indeed, yet I've seen so many people in the strong typing "camp" mentioning "the compiler catches some bugs right away!" as an advantage, which always makes me think "... and?" > It doesn’t matter if your button component calls the onClick handler if that handler doesn't make the right request with the right data! ... But there should be another unit test for that handler, checking that it's using the right request with the right data. In general, I agree with some points and disagree on others.

marcosdumay 9y ago
> every time the code changes, it would be great if a test somewhere broke So, it doesn't matter if your code is correct or not? > "the compiler catches some bugs right away!" as an advantage, which always makes me think "... and?" And that leaves more time to design things right and test the stuff that actually matters.
- luord 9y ago
  > So, it doesn't matter if your code is correct or not? I'm going to need you to walk me so I can see how that part you quoted implies that the code being correct doesn't matter. I honestly don't see the correlation. > And that leaves more time to design things right and test the stuff that actually matters. I'm not gonna get into a religious flamewar; if you prefer static typing, all the power to you and I'm not interested in convincing you otherwise. However, I fail to see how having to write "int", "str", etc before or after a variable name impacts the design process in any way. As for testing: - A test in Go: func TestAvg(t *testing.T) { for _, tt := range []struct { Nos []int Result int }{ {Nos: []int{2, 4}, Result: 3}, {Nos: []int{1, 2, 5}, Result: 2}, {Nos: []int{1}, Result: 1}, {Nos: []int{}, Result: 0}, {Nos: []int{2, -2}, Result: 0}, } { if avg := Average(tt.Nos...); avg != tt.Result { t.Fatalf("expected average of %v to be %d, got %d\n", tt.Nos, tt.Result, avg) } } } - The exact same test in python: def test_average(): for param in [ {'nos': (2, 4), 'res': 3}, {'nos': (1, 2, 5), 'res': 2}, {'nos': (1,), 'res': 1}, {'nos': (), 'res': 0}, {'nos': (2, -2), 'res': 0}, ]: assert average(*param['nos']) == param['res'] In a real situation, tests like this one need to be written and the fact that in Go we're specifying types doesn't change a thing, so I'm not convinced that not writing the types means that in a dynamic language I have to test stuff that doesn't matter. For that matter, I'm having a hard time imagining a scenario where the type wouldn't be tested anyway so back to my "... and?" But, again, I'm also not trying to convince you otherwise. Different approaches for different folks.
  - marcosdumay 9y ago
    > I'm going to need you to walk me so I can see how that part you quoted implies that the code being correct doesn't matter. Well, that quote was your entire sentence. It wasn't out of context. So: > every time the code changes, it would be great if a test somewhere broke There isn't anything anywhere about the code being incorrect. Thus it is irrelevant. About the types, their entire point is that they save you from writing the tests. What the compiler proves, you do not test. If your compiler won't prove anything, you'll have to write all the tests. As an example, you forgot to test if `'nos': ("", None)` yields the correct error.
    - luord 9y ago
      > As an example, you forgot to test if `'nos': ("", None)` yields the correct error. It isn't in the go code either. > There isn't anything anywhere about the code being incorrect. Thus it is irrelevant. Why, exactly? I'm not following your inference there; again, walk me through that one. Let me be more explicit: what exactly did you think I meant with that line? Again, I don't see how it implies that "it doesn't matter whether the code is correct". > About the types, their entire point is that they save you from writing the tests. Ok, this is getting circular so I'll just ask you to give me an example of a test that would be absolutely required in a dynamic language but not in a static one. Mind you, that isn't going to convince me one way or another in the "static vs dynamic" flamewar since I subscribe to the idea that more tests is better. I'm asking mostly out of curiosity.

by luord 9y ago

marcosdumay 9y ago

> every time the code changes, it would be great if a test somewhere broke So, it doesn't matter if your code is correct or not? > "the compiler catches some bugs right away!" as an advantage, which always makes me think "... and?" And that leaves more time to design things right and test the stuff that actually matters.

luord 9y ago
> So, it doesn't matter if your code is correct or not? I'm going to need you to walk me so I can see how that part you quoted implies that the code being correct doesn't matter. I honestly don't see the correlation. > And that leaves more time to design things right and test the stuff that actually matters. I'm not gonna get into a religious flamewar; if you prefer static typing, all the power to you and I'm not interested in convincing you otherwise. However, I fail to see how having to write "int", "str", etc before or after a variable name impacts the design process in any way. As for testing: - A test in Go: func TestAvg(t *testing.T) { for _, tt := range []struct { Nos []int Result int }{ {Nos: []int{2, 4}, Result: 3}, {Nos: []int{1, 2, 5}, Result: 2}, {Nos: []int{1}, Result: 1}, {Nos: []int{}, Result: 0}, {Nos: []int{2, -2}, Result: 0}, } { if avg := Average(tt.Nos...); avg != tt.Result { t.Fatalf("expected average of %v to be %d, got %d\n", tt.Nos, tt.Result, avg) } } } - The exact same test in python: def test_average(): for param in [ {'nos': (2, 4), 'res': 3}, {'nos': (1, 2, 5), 'res': 2}, {'nos': (1,), 'res': 1}, {'nos': (), 'res': 0}, {'nos': (2, -2), 'res': 0}, ]: assert average(*param['nos']) == param['res'] In a real situation, tests like this one need to be written and the fact that in Go we're specifying types doesn't change a thing, so I'm not convinced that not writing the types means that in a dynamic language I have to test stuff that doesn't matter. For that matter, I'm having a hard time imagining a scenario where the type wouldn't be tested anyway so back to my "... and?" But, again, I'm also not trying to convince you otherwise. Different approaches for different folks.
- marcosdumay 9y ago
  > I'm going to need you to walk me so I can see how that part you quoted implies that the code being correct doesn't matter. Well, that quote was your entire sentence. It wasn't out of context. So: > every time the code changes, it would be great if a test somewhere broke There isn't anything anywhere about the code being incorrect. Thus it is irrelevant. About the types, their entire point is that they save you from writing the tests. What the compiler proves, you do not test. If your compiler won't prove anything, you'll have to write all the tests. As an example, you forgot to test if `'nos': ("", None)` yields the correct error.
  - luord 9y ago
    > As an example, you forgot to test if `'nos': ("", None)` yields the correct error. It isn't in the go code either. > There isn't anything anywhere about the code being incorrect. Thus it is irrelevant. Why, exactly? I'm not following your inference there; again, walk me through that one. Let me be more explicit: what exactly did you think I meant with that line? Again, I don't see how it implies that "it doesn't matter whether the code is correct". > About the types, their entire point is that they save you from writing the tests. Ok, this is getting circular so I'll just ask you to give me an example of a test that would be absolutely required in a dynamic language but not in a static one. Mind you, that isn't going to convince me one way or another in the "static vs dynamic" flamewar since I subscribe to the idea that more tests is better. I'm asking mostly out of curiosity.