2 ms·

>> 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

>> 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.
- misterman0 8y ago
  >>Do you trust any The only test that matters to me is the one where a customer says "Yes, good!"
  - detaro 8y ago
    Sure, a test suite doesn't replace that. It helps ensure that test returns "Yes, good!", instead of "Why did you break this thing that worked last week!", assuming you know anything about what the customers consider good.
    - jbn 8y ago
      The parent sounds correct. One can have an extensive test suite and still turn out a product that is useless to the customer. These are 2 entirely separate concerns: testing is sanity checking that the code does what it is written to do, user validation is sanity checking that the code is actually useful to a customer (which most certainly cannot be automated or programmed).
dragonwriter 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...makes no sense. Tests do not understand rules, nor do they (or are they intended to) fully encapsulate them. They are intended to capture specific instances of application of the rules that have been verified with the person(s) defining expectations—the customer for acceptance tests or unit tests of key business functions, but possibly the team itself when the test is a unit test of an implementation detail. The test isn't the only one that understands the ruler, it's the output of a process that validates that the test writers (who are humans on the team) understand the rule, and also concrete examples which aid anyone who comes.later in understanding the rule. To me, not having defined test scenarios (whether automated and thus part of the code base or not) is a signal that the team probably doesn't (and almost definitely doesn't if there has been turnover so that the implementors of the functionality are no longer on the team) fully understand the intended function of the code.

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.

misterman0 8y ago
>>Do you trust any The only test that matters to me is the one where a customer says "Yes, good!"
- detaro 8y ago
  Sure, a test suite doesn't replace that. It helps ensure that test returns "Yes, good!", instead of "Why did you break this thing that worked last week!", assuming you know anything about what the customers consider good.
  - jbn 8y ago
    The parent sounds correct. One can have an extensive test suite and still turn out a product that is useless to the customer. These are 2 entirely separate concerns: testing is sanity checking that the code does what it is written to do, user validation is sanity checking that the code is actually useful to a customer (which most certainly cannot be automated or programmed).

dragonwriter 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...makes no sense. Tests do not understand rules, nor do they (or are they intended to) fully encapsulate them. They are intended to capture specific instances of application of the rules that have been verified with the person(s) defining expectations—the customer for acceptance tests or unit tests of key business functions, but possibly the team itself when the test is a unit test of an implementation detail. The test isn't the only one that understands the ruler, it's the output of a process that validates that the test writers (who are humans on the team) understand the rule, and also concrete examples which aid anyone who comes.later in understanding the rule. To me, not having defined test scenarios (whether automated and thus part of the code base or not) is a signal that the team probably doesn't (and almost definitely doesn't if there has been turnover so that the implementors of the functionality are no longer on the team) fully understand the intended function of the code.