Do everything in Java…

[Chris via Digitalmars-d]

On Friday, 5 December 2014 at 09:27:16 UTC, Paulo  Pinto wrote:
> On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright wrote:
>> On 12/4/2014 5:32 PM, ketmar via Digitalmars-d wrote:
>>>> http://www.teamten.com/lawrence/writings/java-for-everything.html
>>> i didn't read the article, but i bet that this is just 
>>> another article
>>> about his language of preference and how any other language 
>>> he tried
>>> doesn't have X or Y or Z. and those X, Y and Z are something 
>>> like "not
>>> being on market for long enough", "vendor ACME didn't ported 
>>> ACMElib to
>>> it", "out staff is trained in G but not in M" and so on. 
>>> boring.
>>>
>>
>> From the article:
>>
>> "Most importantly, the kinds of bugs that people introduce 
>> most often aren’t the kind of bugs that unit tests catch. With 
>> few exceptions (such as parsers), unit tests are a waste of 
>> time."
>>
>> Not my experience with unittests, repeated over decades and 
>> with different languages. Unit tests are a huge win, even with 
>> statically typed languages.
>
> Yes, but they cannot test everything. GUI code is specially 
> ugly as it requires UI automation tooling.
>
> They do exist, but only enterprise customers are willing to pay 
> for it.
>
> This is why WPF has UI automation built-in.
>
> The biggest problem with unit tests are managers that want to 
> see shiny reports, like those produced by tools like Sonar.
>
> Teams than spend ridiculous amount of time writing superfluous 
> unit tests just to match milestone targets.
>
> Just because code has tests, doesn't mean the tests are testing 
> what they should. But if they reach the magical percentage 
> number then everyone is happy.
>
> --
> Paulo

Now is the right time to confess. I hardly ever use unit tests 
although it's included (and encouraged) in D. Why? When I write 
new code I "unit test" as I go along, with

debug writefln("result %s", result);

and stuff like this. Stupid? Unprofessional? I don't know. It 
works. I once started to write unit tests only to find out that 
indeed they don't catch bugs, because you only put into unit 
tests what you know (or expect) at a given moment (just like the 
old writefln()). The bugs I, or other people, discover later 
would usually not be caught by unit tests simply because you 
write for your own expectations at a given moment and don't 
realize that there are millions of other ways to go astray. So 
the bugs are usually due to a lack of imagination or a tunnel 
vision at the moment of writing code. This will be reflected in 
the unit tests as well. So why bother? You merely enshrine your 
own restricted and circular logic in "tests". Which reminds me of 
maths when teachers would tell us "And see, it makes perfect 
sense!", yeah, because they laid down the rules themselves in the 
first place.

The same goes for comparing your output to some "gold standard". 
The program claims to have an accuracy of 98%. Sure, because you 
wrote for the gold standard and not for the real world where it 
drastically drops to 70%.

The good thing about unit tests is that they tell you when you 
break existing code. But you'll realize that soon enough anyway.