www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Unit Test Suggestions

reply =?iso-8859-1?q?Knud_S=F8rensen?= <knud NetRunner.all-technology.com> writes:
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 22 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
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 23 2004
parent reply Mike Swieton <mike swieton.net> writes:
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 24 2004
parent "Walter" <newshound digitalmars.com> writes:
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 25 2004
prev sibling parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <knud NetRunner.all-technology.com> writes:
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
next sibling parent Mike Swieton <mike swieton.net> writes:
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 26 2004
prev sibling parent Andy Friesen <andy ikagames.com> writes:
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
May 26 2004