4 ms·
Your description does not resemble TDD as I learned it and practice it. > As such the tests often end up containing bugs All code contains bugs, but we do not
by jacques_chester 9y ago
Your description does not resemble TDD as I learned it and practice it.
> As such the tests often end up containing bugs
All code contains bugs, but we do not abandon programming. Having statements of behaviour from outside and inside the solution increases the chances that one will reveal a meaningful difference from the other.
> I just think the 100% test coverage TDD dogma is oversold and doesn't really work well in practice.
I work for Pivotal, one of the most outspokenly pro-TDD shops in the industry. I have, quite literally, never seen or heard any engineer mention test coverage ever.
> Of course I am not a fan of "methodologies" in general. I see them as attempts to replace thinking with rote formula.
I see them as a starting point. The expert mind sees possibility, but the novice mind needs certainty.
- bluGill 9y agoTest coverage doesn't make sense to a TDD shop and so they never talk about it. The only code they have not covered by tests are things that cannot be tested at all. They by definition are as close to 100% coverage as you can be. Test coverage is important in shops that do not do TDD. Such shops are learning the hard way that they need tests to ensure that existing features do not break when they add a new feature. Test coverage is a metric they can use as a proxy for how likely it is that change will break something else (fixing a bug and introducing a new one is a very real problem).