On Friday, 5 December 2014 at 13:23:00 UTC, Russel Winder via
Digitalmars-d wrote:
Developers need to stop thinking "how is this code supposed to
work"
when it comes to tests and start thinking "how can I break this
code".
It is how testers and QA work, sadly developers all too often
fail to.
Yes. this week I met with a compiler guy, which stated roughly:
"It is fairly easy to compile correct code. What is difficult is
handling everything else."
This is particularly relevant for APIs where there is less
likely to be
a QA team involved, and developers not looking for error cases
is why so
many APIs are so broken.
Having the QA far away from dev tend to create a carelessness
amongst them (and for understandable social reasons, QA is
responsibility of the QA department, not us, if something is
wrong, they will tell us).
In my experience, having no QA actually works better. Another
approach is to not have a QA department, but one or 2 QA guys
within the dev team.
One of the failings of TDD is the emphasis on correct cases,
insufficient emphasis on "how can I make this code fail". But
that
doesn't mean co-development of tests and system is a bad thing.
Exactly
the opposite, it is a good thing.
Yes in addition to create less bugs, it also tend to roll out
more decoupled designs (and so testable) design. Decoupled code
have many other benefit than being testable, so that is a good
thing.
So on the one hand I agree with much of your analysis, but I
totally
disagree with your conclusion. Unit, integration and system
tests are
essential. They document the usage of code and outline the test
coverage
and how well the system is likely to work. Even if a system
appears to
work and yet has no tests, it is totally untrustworthy. Best
response to
such code is "rm -rf *".
+1