On Thu, 04 Dec 2014 13:47:53 +0000
Russel Winder via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> It's an argument for Java over Python specifically but a bit more general in reality. This stood out for me:
> 
> 
> !…other languages like D and Go are too new to bet my work on."
> 
> 
> 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.

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.

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.

Well truth to be said, if you don't test, you don't know there is
a bug. Therefore there is no bug.

On Thu, 04 Dec 2014 18:24:26 -0800
Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> 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.
i think that there is some misconception here from the people who says that "unittests are almost useless". such people wants unittests to catch *all* bugs. and when unittests fails at that, people making the conclusion that unittests are not useful at all.

the other thing is that having all unittests separated from the actual code is PITA, at least for me. i really love D unittest feature, thanks to it i wrote alot more unittests in my D code than in the code in other languages i'm using. and having ddoc in compiler encourages me to write at least a minimal documentation for the source. ;-)

yes, i know about doxygen, unittesting frameworks and so on. somehow they never works for me. "ah, those tools are second class citizens, i'll do 'em favor later." of course, that "later" means "never" most of the time. ;-)

and what i also can't grok is "test-driven developement". ah, we spent alot of time writing that tests that we can't even run 'cause we didn't start working on the actual code yet. it's splendid! we didn't start the real work yet and we are already bored. i don't believe that this is a good way to develop a good project.

On 12/4/2014 6:47 PM, ketmar via Digitalmars-d wrote:
> and what i also can't grok is "test-driven developement". ah, we spent
> alot of time writing that tests that we can't even run 'cause we didn't
> start working on the actual code yet. it's splendid! we didn't start
> the real work yet and we are already bored. i don't believe that this
> is a good way to develop a good project.

What I find most effective is writing the unit tests and the code they drive at the same time.

On Thu, 04 Dec 2014 21:03:59 -0800
Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 12/4/2014 6:47 PM, ketmar via Digitalmars-d wrote:
> > and what i also can't grok is "test-driven developement". ah, we spent alot of time writing that tests that we can't even run 'cause we didn't start working on the actual code yet. it's splendid! we didn't start the real work yet and we are already bored. i don't believe that this is a good way to develop a good project.
> 
> What I find most effective is writing the unit tests and the code they drive at the same time.
that's it. programmer needs something to test his newly written code anyway, so tests are natural here. some tests can be added as a reminders: "oh, and i want it to do this too, but don't want it to distract me right now. let's add a test for it, so i will not forget about it later." failed tests works, "TODO" comments are not. ;-)

On Friday, 5 December 2014 at 02:47:51 UTC, ketmar via Digitalmars-d wrote:
> yes, i know about doxygen, unittesting frameworks and so on. somehow
> they never works for me. "ah, those tools are second class citizens,
> i'll do 'em favor later." of course, that "later" means "never" most of
> the time. ;-)

In this case I just return task to the developer with a requirement to write a test. D builtin unittests are not suited for complex integration tests, because they are all or nothing and tests easily become brittle, we never have all green builds.

On Fri, 05 Dec 2014 08:56:42 +0000
Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Friday, 5 December 2014 at 02:47:51 UTC, ketmar via Digitalmars-d wrote:
> > yes, i know about doxygen, unittesting frameworks and so on.
> > somehow
> > they never works for me. "ah, those tools are second class
> > citizens,
> > i'll do 'em favor later." of course, that "later" means "never"
> > most of
> > the time. ;-)
> 
> In this case I just return task to the developer with a requirement to write a test. D builtin unittests are not suited for complex integration tests, because they are all or nothing and tests easily become brittle, we never have all green builds.
that may work for big team projects. but i'm speaking of hobby/tiny team projects here. sure i can return task to myself, but this will not help. ;-)

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

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.