5 ms·

Atom's Go integration re-runs tests after save to a .go file. It's very convenient because you can see test failures and test coverage changes immediately. But

by kjksf 9y ago

Atom's Go integration re-runs tests after save to a .go file. It's very convenient because you can see test failures and test coverage changes immediately. But it's slow if you modified a file that is not involved in tested code paths. This is just one concrete example. In general when the code size grows, very quickly it becomes impossible to tell if a given edit could possibly affect tests or not. So you want to run `go test` just in case so making it faster is a good thing.

kasey_junk 9y ago
But this isn’t doing ‘intelligent’ caching, just like go doesn’t do intelligent test checking. If the test binary changes (I think that implies basically any change in the package) the tests rerun.
- kjksf 9y ago
  In general the bar for making changes is: is it better that it was yesterday? Before 1.10 `go test` used to re-run tests unconditionally. Since 1.10 it'll avoid re-running them in some cases. Neither me nor the announcement claims "intelligence". The rules are simple and effective which is the Go Way. While you could try to make even better, more "intelligent" rules for determining wether to re-run the tests, those would quickly run into engineering complexity chasing diminishing returns. That is not the Go Way.
  - kasey_junk 9y ago
    There are lots of things on my list you could do that were simple & effective that would provide me more value than this. Historically the argument against them have been about adding needless complexity. I wonder who was asking for this and how they got it prioritized.
    - rhencke 9y ago
      It was requested by rsc in 2015: https://github.com/golang/go/issues/11193 https://github.com/golang/go/issues/11193 It was implemented by rsc subsequently, after discussion on the issue: https://go-review.googlesource.com/c/go/+/75631 https://go-review.googlesource.com/c/go/+/75631 I'm not sure what you're trying to insinuate.
      - kasey_junk 9y ago
        I’m not insinuating anything. I’m flat saying this seems like a low value feature. Other higher value features are denied on the basis of unneeded complexity.
        maloney 9y ago
        I mean, the project lead wanted a feature and then implemented the feature, clearly it had value to him.
        slrz 9y ago
        The difference is that this feature (ideally) only affects implementation complexity, not interface complexity. It can also be dropped again tomorrow without breaking the world. This makes it wildly different from language changes, which require a lot more consideration.

by kjksf 9y ago

kasey_junk 9y ago

But this isn’t doing ‘intelligent’ caching, just like go doesn’t do intelligent test checking. If the test binary changes (I think that implies basically any change in the package) the tests rerun.

kjksf 9y ago
In general the bar for making changes is: is it better that it was yesterday? Before 1.10 `go test` used to re-run tests unconditionally. Since 1.10 it'll avoid re-running them in some cases. Neither me nor the announcement claims "intelligence". The rules are simple and effective which is the Go Way. While you could try to make even better, more "intelligent" rules for determining wether to re-run the tests, those would quickly run into engineering complexity chasing diminishing returns. That is not the Go Way.
- kasey_junk 9y ago
  There are lots of things on my list you could do that were simple & effective that would provide me more value than this. Historically the argument against them have been about adding needless complexity. I wonder who was asking for this and how they got it prioritized.
  - rhencke 9y ago
    It was requested by rsc in 2015: https://github.com/golang/go/issues/11193 https://github.com/golang/go/issues/11193 It was implemented by rsc subsequently, after discussion on the issue: https://go-review.googlesource.com/c/go/+/75631 https://go-review.googlesource.com/c/go/+/75631 I'm not sure what you're trying to insinuate.
    - kasey_junk 9y ago
      I’m not insinuating anything. I’m flat saying this seems like a low value feature. Other higher value features are denied on the basis of unneeded complexity.
      - maloney 9y ago
        I mean, the project lead wanted a feature and then implemented the feature, clearly it had value to him.
      - slrz 9y ago
        The difference is that this feature (ideally) only affects implementation complexity, not interface complexity. It can also be dropped again tomorrow without breaking the world. This makes it wildly different from language changes, which require a lot more consideration.