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.
