Do everything in Java…

[Ary Borenszweig via Digitalmars-d]

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.