On Monday, 8 December 2014 at 16:04:31 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Mon, Dec 08, 2014 at 11:22:45AM +0000, Chris via Digitalmars-d wrote:
> [...]
>> What I gather from all the posts about code reviews and testing is
>> that it's a solid mess out there, and the bigger the company the
>> bigger the mess. I'm pretty much the only guy who works on the code at
>> the moment and sometimes feel a bit bad about failing to update this
>> or that (unit) test (simply because I lack the time). On the other
>> hand the code and the programs are constantly being tested in the real
>> world and are very stable.
>
> Sounds like you're actually in a pretty good state, compared with the
> rest of the industry out there! :-P

Well, I don't have to meet deadlines all the time and deal with customers who've been promised by someone in the management that you can turn straw into gold. I don't need feature X until tomorrow (or yesterday), but can think about a proper implementation first. Thankfully we have someone on the team who can test the software immediately and thoroughly before we give it out (or use it internally).

>> This might be due to the fact, that I "unit test" a lot during
>> development (code a little, test a little). It is also down to the
>> fact that the D compiler often helps me and warns me immediately. It's
>> not so easy to get away with dodgy code in D.
>
> Yeah, D does fix a lot of the flaws with C/C++ that allow you to shoot
> yourself in the foot and then erase all evidence of it. While D does
> have its own share of dark corners, it's generally very pleasant to work
> with, and does encourage good coding style.

D does have dark corners, but only if you care to go there, and sooner or later (rather sooner than later) your house of cards will collapse, because the dodgy code is often "found out" by the proper code. I've always had to rewrite any dodgy, highly unsafe code I introduced to save a nanosecond - and the dodgy code is usually due to some interaction with C!

>> Regarding the working hours, it is hard to measure efficiency in
>> working hours when it comes to software development. Sometimes a major
>> improvement takes only one or two hours of highly concentrated work
>> (after which the brain is wrecked). Sometimes a stupid little problem
>> takes a whole day to sort out. And let's not forget that programmers
>> often tend to think about how to solve a certain problem after work. I
>> often found it more efficient to shut down the computer and go home
>> than to keep on trying to find a bug when I'm already tired and
>> annoyed. The next morning (with a fresh head) I often spot the bug
>> immediately. Or I think of the right solution on my way home. Mere
>> working hours don't count.
>
> Yep. I have experienced this many times. Sometimes repeatedly trying to
> attack a problem eventually gets to a point where my brain is just
> overwhelmed and cannot make any further progress, but when I take a walk
> and relax for a few minutes, my subconscious brain clears up and
> suddenly the solution pops into my head seemingly out of nowhere. I've
> had occasions where I wake up in the middle of the night with the
> solution in my head -- at least once, I actually got up at 6am and drove
> to work just to implement what I became convinced was the fix, and found
> that it in fact was, whereas many hours of intense concentration the day
> before got me nowhere.
>
>
> T

On 05/12/2014 15:03, 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.

"Unit tests are not for detecting bugs" -> What the hell?... ఠ_ఠ

1. "Making sure things work":  Writing unit tests does not make a broken program start working just fine! It just helps you detect the program is broken, and also, more or less *where* is which part of the code is broken. This is essentially, detecting a bug. To actually make things work, you have to fix the bug.

2. "Making sure things continue to work": Yes, but again same as 1, the unit tests by themselves don't help keep the program working correctly. Rather, they help you detect when regressions are introduced. And regressions are bugs.

3. LOL. It doesn't make the bug impossible to resurrect, it just makes you detect it as soon as it reappears. Again, detecting bugs...

4. True, unit tests can have some value as documentation, or helping you design your code/API in the initial stages of implementation. But these are secondary aspects of unit tests. The primary and by far most significant purpose of unit tests is to help detect bugs!


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros