Knud Soerensen wrote:
Some time ago I need a script to get and process some data.
I trough why not use D, but I couldn't find a function in the standard
library which would get a simple web page with http.
Instead of find and downloading other libraries I switched to peal and
had it running in no time.
I think it is the choice of problem domain for D.
I'd love to have some functions in Phobos that do this. Can you write a
module and contribute it? Phobos is definitely short on a lot of
networking functionality.
I know the real focus for D system programing and the C++ people.
I think one of D's strongest points for people to make the switch is
build in unit testing. (at least this is the strongest point for me)
But the very simple implementation of unit testing in D nearly ruin the
advantage it gives. (see suggestion from the wishlist below)
Even at its very simple support, it's a huge win. It raises the bar on
what is minimally acceptable, and has been responsible for a big
improvement in the quality of Phobos.
A simple way to ensure that could if the compiler issued a error/warning
if a function had no unit tests or contracts.
I worry that such would be crying wolf. But dmd does have a coverage
analyzer built in - which I think is more useful. It'll show which lines
were executed by the unit tests, and which were not.
What follows is some unit test suggestions from
http://all-technology.com/eigenpolls/dwishlist
Because I would like to hear your opinion about them.
** unit test & code separation
I think it would be more useful if the code
and the unit test where two separate binaries.
Sometimes you need to move the production binary to another
machine/environment.
It would be nice if one could move the test binary with it and test that
everything works.
It would also allow for arguments to the test binary,
so that you would be able to run a specific unit test.
I made the decision at one point that unit tests weren't there to test
that the compiler generated code correctly, they were to test the logic
of the user code. Hence, one does a separate build for unit tests than
production release.
The release version should get the black box tests, not unit tests.
** black box unit testing
The d compiler should enforce black box unit tests.
Which is unit tests that only use the classes exposed interface.(public,
protected)
Together with 100% unit test coverage it helps ensure that
the code is modular,decoupled and that you can change
the private parts without changing the unit tests.
For those how is not ready for this high code standard,
there might be a --allow-white-box switch.
The compiler doesn't need to help here. There's nothing preventing one
from using unittests in this manner. Just import the .di file, which is
the exposed interface, then write a unit test block.
** Unit test isolation
I would like to be able to isolate the unit test,
so that if one fail the next still runs.
You can do this by simply not using "assert" for the actual test. Use:
if (!x) writeln("test for x failed");
instead of:
assert(x);
You can, of course, make a template like Andrei's enforce() to make the
if test and message a bit more convenient.
** Unit test measurements
In combination with test isolation
it would be nice to have d output
memory and time used in each unit test.
Use the -profile switch.
