Do everything in Java…

Chris via Digitalmars-d digitalmars-d at puremagic.com
Fri Dec 5 07:28:35 PST 2014


On Friday, 5 December 2014 at 15:25:19 UTC, Ary Borenszweig wrote:
> On 12/5/14, 12:11 PM, Chris wrote:
>> 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.
>
> This is very true. Specially when mocks come into play, 
> sometimes test become duplicated code and every time you make 
> changes in your codebase you have to go and change the expected 
> behaviour of mocks, which is just tedious and useless.

Thanks for saying that. That's my experience too, especially when 
a module is under heavy development with frequent changes.


More information about the Digitalmars-d mailing list