3 ms·

TDD only works if the tests are written correctly. Tests are not about "code coverage", nor about establishing the exact sequence of things in stone. Tests are

TDD only works if the tests are written correctly. Tests are not about "code coverage", nor about establishing the exact sequence of things in stone. Tests are about fixing invariants. When a new project starts, I only know about 10-15% things for sure, and those are exactly which will go in tests, before writing any new code. I don't worry about some things in my code are not yet covered by tests; I don't know yet how they will turn out, so I can't write any meaningful invariants. In my experience, useful tests are much higher-level than TDD guys prefer. They routinely fix invariants for the entire system / subproject, not assuring coverage of every method in class (some crazy folks are even testing getters and setters — why?)

tragic 11y ago
> some crazy folks are even testing getters and setters — why? Well, I can see the logic if your getters and setters are hiding more activity than simply retrieving/setting the value of a private field, which is the point of having separate getters/setters at all. If you imagine a getFullName() / setFullName(name) pair, for example, that actually reads from/writes to two different private fields for first and last name (leaving aside middle names, internationalisation, etc), then there's some minimal logic there that you might want to test. In a duck-typed language, when you're trying to ensure a class obeys an implicit interface, it may also have value. Apart from that, for vanilla getters/setters, it's a little pointless.
- atemerev 11y ago
  In such case, a correct test should focus on functional invariants, like getFullName() + " " + getLastName() equals to getName() (btw, never do that — names are much more complicated than that. In some countries, there are no first and last names at all; others use multiple name designations; some have meaningful patronyms etc.)
  - tragic 11y ago
    I agree (and implied) it was not a great design for actually dealing with names, but simply that sometimes there is more in getFoo() than "return foo". Which behaviour you may want to verify with a test. EDIT: typo

tragic 11y ago

> some crazy folks are even testing getters and setters — why? Well, I can see the logic if your getters and setters are hiding more activity than simply retrieving/setting the value of a private field, which is the point of having separate getters/setters at all. If you imagine a getFullName() / setFullName(name) pair, for example, that actually reads from/writes to two different private fields for first and last name (leaving aside middle names, internationalisation, etc), then there's some minimal logic there that you might want to test. In a duck-typed language, when you're trying to ensure a class obeys an implicit interface, it may also have value. Apart from that, for vanilla getters/setters, it's a little pointless.

atemerev 11y ago
In such case, a correct test should focus on functional invariants, like getFullName() + " " + getLastName() equals to getName() (btw, never do that — names are much more complicated than that. In some countries, there are no first and last names at all; others use multiple name designations; some have meaningful patronyms etc.)
- tragic 11y ago
  I agree (and implied) it was not a great design for actually dealing with names, but simply that sometimes there is more in getFoo() than "return foo". Which behaviour you may want to verify with a test. EDIT: typo