View mode: basic / threaded / horizontal-split · Log in · Help
May 23, 2004
Unit Test Suggestions
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
Re: Unit Test Suggestions
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
Re: Unit Test Suggestions
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
Re: Unit Test Suggestions
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
Re: Unit Test Suggestions
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
Re: Unit Test Suggestions
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
Re: Unit Test Suggestions
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