May 23, 2004
Hi

I have posted some unit test suggestions on the D Language Design Wiki at http://dlanguage.netunify.com/59

with suggestions on

Test isolation.
Performances of tested code.
Parser friendly test output.
Test coverage.

feel free to add your own.

Knud
May 23, 2004
They're good ideas.

"Knud Sørensen" <knud@NetRunner.all-technology.com> wrote in message news:pan.2004.05.23.00.31.58.247763@NetRunner.all-technology.com...
> Hi
>
> I have posted some unit test suggestions on the
> D Language Design Wiki at
> http://dlanguage.netunify.com/59
>
> with suggestions on
>
> Test isolation.
> Performances of tested code.
> Parser friendly test output.
> Test coverage.
>
> feel free to add your own.
>
> Knud


May 25, 2004
Does this mean we can expect changes in unit testing? Have you a surprise for us?

I would like to point out my earlier proposal, which also identifies problems with D's unit testing: http://www.digitalmars.com/drn-bin/wwwnews?D/26354 There's a lot of overlap, but I go at it from a different direction.

On Sun, 23 May 2004 10:51:03 -0700, Walter wrote:

> They're good ideas.
> 
> "Knud Sørensen" <knud@NetRunner.all-technology.com> wrote in message news:pan.2004.05.23.00.31.58.247763@NetRunner.all-technology.com...
>> Hi
>>
>> I have posted some unit test suggestions on the
>> D Language Design Wiki at
>> http://dlanguage.netunify.com/59
>>
>> with suggestions on
>>
>> Test isolation.
>> Performances of tested code.
>> Parser friendly test output.
>> Test coverage.
>>
>> feel free to add your own.
>>
>> Knud



Mike Swieton
__
We owe most of what we know to about one hundred men. We owe most of what we
have suffered to another hundred or so.
	- R. W. Dickson

May 25, 2004
Not in the near future. I'm pretty overloaded out to the horizon right now :-(

"Mike Swieton" <mike@swieton.net> wrote in message news:pan.2004.05.25.01.37.15.876151@swieton.net...
> Does this mean we can expect changes in unit testing? Have you a surprise
for
> us?
>
> I would like to point out my earlier proposal, which also identifies problems with D's unit testing: http://www.digitalmars.com/drn-bin/wwwnews?D/26354 There's a lot of
overlap,
> but I go at it from a different direction.
>
> On Sun, 23 May 2004 10:51:03 -0700, Walter wrote:
>
> > They're good ideas.
> >
> > "Knud Sørensen" <knud@NetRunner.all-technology.com> wrote in message news:pan.2004.05.23.00.31.58.247763@NetRunner.all-technology.com...
> >> Hi
> >>
> >> I have posted some unit test suggestions on the
> >> D Language Design Wiki at
> >> http://dlanguage.netunify.com/59
> >>
> >> with suggestions on
> >>
> >> Test isolation.
> >> Performances of tested code.
> >> Parser friendly test output.
> >> Test coverage.
> >>
> >> feel free to add your own.
> >>
> >> Knud
>
>
>
> Mike Swieton
> __
> We owe most of what we know to about one hundred men. We owe most of what
we
> have suffered to another hundred or so.
> - R. W. Dickson
>


May 26, 2004
I have just added.


 Unit tests which have direct access to
the private parts of a class,
make the class mode difficult to refactor.
Unit tests which only access the class
by the public interface and still
have 100% test coverage insure that
the interface is complete and robust.

If access to the private parts from the
unit tests is necessary then
the class design should be reconsidered.

So, either should D disallow this
or it should at least give a warning
when compiling.


On Sun, 23 May 2004 02:31:58 +0200, Knud Sørensen wrote:

> Hi
> 
> I have posted some unit test suggestions on the D Language Design Wiki at http://dlanguage.netunify.com/59
> 
> with suggestions on
> 
> Test isolation.
> Performances of tested code.
> Parser friendly test output.
> Test coverage.
> 
> feel free to add your own.
> 
> Knud

-- 
Join My Network http://connect.tickle.com/invitation.html?uid=muljlVUnO32u8sSZ

May 26, 2004
On Wed, 26 May 2004 21:49:46 +0200, Knud Sørensen wrote:

> I have just added.
> 
> 
>  Unit tests which have direct access to the private parts of a class, make
>  the class mode difficult to refactor.  Unit tests which only access the
>  class by the public interface and still have 100% test coverage insure that
>  the interface is complete and robust.
> 
> If access to the private parts from the unit tests is necessary then the class design should be reconsidered.
> 
> So, either should D disallow this or it should at least give a warning when compiling.
> 

I cannot possibly disagree with this strongly enough. The reason is this: if you can only unit test using the public interface, you will have tests that depend on mulitple units. The advantage to allowing private access is that I can test a method with side effects without needing to use any of the other methods in the class. This is a good thing, because it means the test depends on less code. The test is of narrower and more explicit scope.

Aside from the debate as to good testing practices, the language should absolutely not be enforcing it.

Besides, you can get that functionality now if you really want it by just putting your unit tests in a different module.

There are shortcomings in D's unit testing, but this will not improve things whatsoever.

Mike Swieton
__
Go on, get out. Last words are for fools who haven't said enough.
	- Karl Marx, last words

May 27, 2004
Knud Sørensen wrote:

> If access to the private parts from the
> unit tests is necessary then
> the class design should be reconsidered.

It's rather hard to perform proper white box testing if you can't get inside the box. :)

 -- andy
Top | Discussion index | About this forum | D home