On Friday, 8 May 2015 at 14:00:01 UTC, Chris wrote:
On Friday, 8 May 2015 at 13:31:38 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 8 May 2015 at 08:45:07 UTC, Walter Bright wrote:
On 5/8/2015 1:16 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
<ola.fosheim.grostad+dl...@gmail.com>" wrote:
And people don't pick a language because of a testing
framework…
Which is why I need to point out just how productivity
boosting -unittest and -cov are.
D unittests can be neat for simpler libraries, but they also
make code harder to browse. Phobos source code clearly suffers
from it.
So I'd rather have them separate and have testing-support
built into the IDE instead. I find that cleaner as unit-tests
are actually not part of the semantical language, just part of
the D syntax...
You are probably right that people use them more when they are
"shipped with the product", though. Whether you ship the
compiler or a bundle (IDE).
I like unittests in phobos and other libraries, because they
immediately show me how to use the code, and I like how simple
it is:
dub --build=unittest
or
dmd myfile.d -unittest
Be honest, have you written unittests for each your Python
scripts, for each of your command line tools? D makes it easy
for you.
The only drawback is that sometimes the logic of a program does
not allow to test every little bit, especially when handling
files is concerned. But overall D in general makes me more
"code aware" in many respects, be it performance, code hygiene
or re-usability. And it helps that the compiler ships with a
lot of flags that help me to analyze my code.
The funny thing is that people keep complaining about the lack of
tools for D, and when a tool is built into the language they say
"That tool shouldn't be part of the language". Yet, if it were
omitted, people would say "Why doesn't D have this tool built
in?". Human nature, I guess.
