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