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.
I read some comments in D code on github saying "extend unit test
to include XYZ". So it's already been tested, it works and it
will never be added, just like the
debug writeln()
disappears after the code has been thoroughly tested. If there's
a bug, it's not the XYZ that has been tested but the ZYX nobody
thought of (or couldn't think of, because it works as unexpected
on Windows) :-).
Usually you run standard tests anyway to see if the old stuff
still works as expected. Designing unit tests for each module is
a bit tedious. And what if you change a function/method? The unit
tests will break and you have to write new ones or comment them
out. Blah blah blah.
Maybe people expect too much from unit test. They are just a way
to test if the program still works as expected in the most
obvious cases. But they are not a debugging tool.
