Do everything in Java…

[Chris via Digitalmars-d]

On Friday, 5 December 2014 at 15:03:39 UTC, Ary Borenszweig wrote:
> On 12/5/14, 9:42 AM, Chris wrote:
>> On Friday, 5 December 2014 at 12:06:55 UTC, Nemanja Boric 
>> wrote:
>>>> The good thing about unit tests is that they tell you when 
>>>> you break
>>>> existing code.
>>>
>>> That's the great thing about unittests, and the reason why I 
>>> write
>>> unittests. I work on a fairly complex code base and every now 
>>> and then
>>> there's a new feature requested. Implementing features 
>>> involves
>>> several to dozen of modules to be changed, and there's no way 
>>> that I
>>> could guarantee that feature implementation didn't change 
>>> behaviour of
>>> the existing code. I both hate and love when I `make` 
>>> compiles and
>>> unittest fails.
>>>
>>>> But you'll realize that soon enough anyway.
>>>
>>> This is not good enough for me. Sometimes "soon enough" means 
>>> week or
>>> two before somebody actually notice the bug in the 
>>> implementation
>>> (again, very complex project that's simply not 
>>> hand-testable), and
>>> that's definitively not soon enough keeping in mind amount of 
>>> $$$ that
>>> you wasted into air.
>>>
>>>
>>>
>>> On Friday, 5 December 2014 at 11:53:11 UTC, Chris wrote:
>>>> 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.
>>
>> Yes, yes, yes. Unit tests can be useful in cases like this. 
>> But I don't
>> think that they are _the_ way to cope with bugs. It's more 
>> like "stating
>> the obvious", and bugs are hardly ever obvious, else they 
>> wouldn't be bugs.
>
> Unit tests are not for detecting bugs. They are only useful for:
>
> 1. Making sure things work (a bit).
> 2. Making sure things continue to work when you refactor or 
> introduce new code.
> 3. When a new bug is found you can write a test for it that 
> will make that bug impossible to ever resurrect.
> 4. Show how code is supposed to be used.
>
> Again, their purpose is not to detect bugs, but to build more 
> robust software.

I completely agree with all your points. Point 4 I forgot to 
mention, I often look at the unit tests in D source code to see 
how it is supposed to be used. All I'm saying is that sometimes 
unit tests are sold as the be all end all anti-bug design. I 
think they should be used sensibly not everywhere.