Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Knud Sørensen | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Swieton | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Knud Sørensen | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Knud Sørensen | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Knud Sørensen | 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
|
Copyright © 1999-2021 by the D Language Foundation