5 ms·

> Who could argue with these? Maybe not argue, but I still find this link useful. I will link it to more junior engineers in my team. Believe it or not, not ev

> Who could argue with these? Maybe not argue, but I still find this link useful. I will link it to more junior engineers in my team. Believe it or not, not everybody does self-review before they ask for peer review.

misterman0 8y ago
>> Believe it or not, not everybody does self-review That's not hard to believe given the stream of shit that comes out of a feed, any feed. But I'm appalled by y'all's assumption that #3 is a given. Why do you all believe that? To me, including a test suite in your code base is a code smell.
- ponyous 8y ago
  Well depends, having 0 testing sucks too. I would argue 100% TDD can be a code smell, especially if you try to unit test everything. Use testing where it makes sense. Got some complex business logic in some function with several different edge cases? Cover them in test cases, it will also serve as documentation. If you have a problem with #3 you might as well have the problem with #5. You don't want to automate everything, only where it makes sense.
  - misterman0 8y ago
    >> Use testing where it makes sense. I agree! >> Got some complex business logic So complex the only one who understands it is...who? A test?
    - volkk 8y ago
      i'm not sure what you're arguing here. if you have a complicated codebase you write tests so that when you add other code, you have a bit more confidence that you're not breaking things. furthermore, if a new person joins a team, they can use old tests to understand what the hell is happening in the code otherwise you just have an unadulterated mess of code to read through. you're dealing with humans on a day to day basis that err very easily. the dumb mistakes i've made because there was a lack of tests are countless.
- detaro 8y ago
  Why do you think having tests is a code smell? Sure, you can overdo it, but testing is useful and it's wasteful to have humans do it where it isn't necessary.
  - misterman0 8y ago
    >> Why do you think having tests is a code smell? Because it signals to me that the only one who understands this piece of business logic that we have applied to our code base is a test, which is a piece of code. Why should I trust this piece of code but not this other piece? What pieces of code should I trust? Me, I don't trust tests.
    - detaro 8y ago
      > Because it signals to me that the only one who understands this piece of business logic that we have applied to our code base is a test, which is a piece of code. That's a weird leap of logic. No, it does not mean that. It means that a human wo understood that piece of logic wrote a test, so the test can in the future warn about issues before a human spends time on checking if it still works like it should.
      - misterman0 8y ago
        I disagree with the notion that this leap is weird. >> No, it does not mean that. It means that a human wo understood that piece of logic wrote a test I don't not trust a human to understand (1) a piece of logic nor to understand (2) a test written by someone who does not understand said piece of logic.
        detaro 8y ago
        So how are you implementing code when you don't understand the logic of what it does? How do you make sure it does what it is supposed to do?
    - asark 8y ago
      Do you trust any documentation at all? A test's just documentation a machine can read and, to some extent, validate. Other docs are necessarily even less trustworthy, if they can't be automatically checked for accuracy.
- asark 8y ago
  > To me, including a test suite in your code base is a code smell. You'd put it somewhere else, then?
  - misterman0 8y ago
    My point is, you shouldn't need one. - "But my code base is so big and complex!" Make it smaller.
    - nradov 8y ago
      Some problems are irreducibly complex. There is no way to make the code smaller or simpler without losing essential functionality or performance.
      - jbn 8y ago
        This is so true. If the problem domain is so small that you can get away with no tests (only small programs or small teams can indeed get away with it, IMHO), then it cannot be a system of interest. For large systems (i.e. systems so large that any one human cannot fully grasp them), testing is required. Testing does not prove much about the system, it only encodes the assertions of the programmers about how it is meant to work. Testing is merely a harness that constrains the flight domain of the code, it does not guarantee that the code within the flight domain is correct, only that it presents a certain level of certainty about it. Above some system size, the certainty of correctness is merely probabilistic, and automated testing is what gives you assurance. Programming without testing is like driving with a seatbelt: sure it is feasible, but it's insane to do it.
    - GorgeRonde 8y ago
      Tests aren't written to simply assert complex things behave as they should. Tests are also used to enforce certain edge cases (e.g. return nil when the the input collection is empty instead of raising an exception), and in this regard allow you to assert stuff your language isn't able to express (because its type system is not as powerful as Haskell for instance). Tests also allow you to avoid stupid mistakes like using a string instead of a symbol as well. And anyway, tests are just a way to durably persist the testing that is always done by a programmer, be it in a REPL or with the few lines of codes at the end of a file used in the writing of code.

misterman0 8y ago

>> Believe it or not, not everybody does self-review That's not hard to believe given the stream of shit that comes out of a feed, any feed. But I'm appalled by y'all's assumption that #3 is a given. Why do you all believe that? To me, including a test suite in your code base is a code smell.

ponyous 8y ago
Well depends, having 0 testing sucks too. I would argue 100% TDD can be a code smell, especially if you try to unit test everything. Use testing where it makes sense. Got some complex business logic in some function with several different edge cases? Cover them in test cases, it will also serve as documentation. If you have a problem with #3 you might as well have the problem with #5. You don't want to automate everything, only where it makes sense.
- misterman0 8y ago
  >> Use testing where it makes sense. I agree! >> Got some complex business logic So complex the only one who understands it is...who? A test?
  - volkk 8y ago
    i'm not sure what you're arguing here. if you have a complicated codebase you write tests so that when you add other code, you have a bit more confidence that you're not breaking things. furthermore, if a new person joins a team, they can use old tests to understand what the hell is happening in the code otherwise you just have an unadulterated mess of code to read through. you're dealing with humans on a day to day basis that err very easily. the dumb mistakes i've made because there was a lack of tests are countless.
detaro 8y ago
Why do you think having tests is a code smell? Sure, you can overdo it, but testing is useful and it's wasteful to have humans do it where it isn't necessary.
- misterman0 8y ago
  >> Why do you think having tests is a code smell? Because it signals to me that the only one who understands this piece of business logic that we have applied to our code base is a test, which is a piece of code. Why should I trust this piece of code but not this other piece? What pieces of code should I trust? Me, I don't trust tests.
  - detaro 8y ago
    > Because it signals to me that the only one who understands this piece of business logic that we have applied to our code base is a test, which is a piece of code. That's a weird leap of logic. No, it does not mean that. It means that a human wo understood that piece of logic wrote a test, so the test can in the future warn about issues before a human spends time on checking if it still works like it should.
    - misterman0 8y ago
      I disagree with the notion that this leap is weird. >> No, it does not mean that. It means that a human wo understood that piece of logic wrote a test I don't not trust a human to understand (1) a piece of logic nor to understand (2) a test written by someone who does not understand said piece of logic.
      - detaro 8y ago
        So how are you implementing code when you don't understand the logic of what it does? How do you make sure it does what it is supposed to do?
  - asark 8y ago
    Do you trust any documentation at all? A test's just documentation a machine can read and, to some extent, validate. Other docs are necessarily even less trustworthy, if they can't be automatically checked for accuracy.
asark 8y ago
> To me, including a test suite in your code base is a code smell. You'd put it somewhere else, then?
- misterman0 8y ago
  My point is, you shouldn't need one. - "But my code base is so big and complex!" Make it smaller.
  - nradov 8y ago
    Some problems are irreducibly complex. There is no way to make the code smaller or simpler without losing essential functionality or performance.
    - jbn 8y ago
      This is so true. If the problem domain is so small that you can get away with no tests (only small programs or small teams can indeed get away with it, IMHO), then it cannot be a system of interest. For large systems (i.e. systems so large that any one human cannot fully grasp them), testing is required. Testing does not prove much about the system, it only encodes the assertions of the programmers about how it is meant to work. Testing is merely a harness that constrains the flight domain of the code, it does not guarantee that the code within the flight domain is correct, only that it presents a certain level of certainty about it. Above some system size, the certainty of correctness is merely probabilistic, and automated testing is what gives you assurance. Programming without testing is like driving with a seatbelt: sure it is feasible, but it's insane to do it.
  - GorgeRonde 8y ago
    Tests aren't written to simply assert complex things behave as they should. Tests are also used to enforce certain edge cases (e.g. return nil when the the input collection is empty instead of raising an exception), and in this regard allow you to assert stuff your language isn't able to express (because its type system is not as powerful as Haskell for instance). Tests also allow you to avoid stupid mistakes like using a string instead of a symbol as well. And anyway, tests are just a way to durably persist the testing that is always done by a programmer, be it in a REPL or with the few lines of codes at the end of a file used in the writing of code.