Reddit: why aren't people using D?

[Knud Soerensen]

Walter Bright wrote:

>> 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.
Yes, but the chose is not about unit test or no unit test.

It is between using D with its very simple unit test framework or 
C++/java/etc with a very good unit testing framework.

I think that D should provide a framework on the same level
or maybe just make the best unit testing framework on the planet.



> 
>> 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.

Yes, the coverage analyzer is very good, but how do you ensure that the 
library developers actually use it ??

The feature should be introduce slowly, by first printing a warning when 
a testing binary was build.
Then step it up to a error for testing binary.
Then a warning for production binaries
and in a dissent future also errors on production binaries.

Already at the first step, we would see if the D community find it useful.

In its last step it would unsure that everybody using
some unknown D code would know that it had some level of test coverage
and quality.

It is not as fine masked as 100% coverage test but would ensure that
ever function had some test code and that without run a coverage analyzes.

How hard do you think it would be to make ?


> 
> 
>>
>> 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.
> 
Running unit test in another environment is god for testing
if the assumptions you make in your code about the environment is correct.





> 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.

Yes, you can do that.
But why should you have to jump trough loops to write good test code.
I think the default behavior should support writing good modular tests.

Imagine we have a team with 20 programmers working a big project.
The project standard for unit testing is to include .di file and write 
unit test on the public interface.
Now imagine one bad programmer broke the standard and wrote a unit test 
on a private function.

Now, how would you discover that, without going trough every d file ?

If it is default behavior was not to allow unit testing private function 
then the bad programmer would have to use the --allow-white-box switch 
and you could just compile without it to discover the problem.

-- 
Join me on
CrowdNews  http://crowdnews.eu/users/addGuide/42/
Facebook   http://www.facebook.com/profile.php?id=1198821880
Linkedin   http://www.linkedin.com/pub/0/117/a54
Mandala    http://www.mandala.dk/view-profile.php4?profileID=7660