Do everything in Java…

[deadalnix via Digitalmars-d]

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