|
Archives
D Programming
DD.gnu digitalmars.D digitalmars.D.bugs digitalmars.D.dtl digitalmars.D.dwt digitalmars.D.announce digitalmars.D.learn digitalmars.D.debugger C/C++ Programming
c++c++.announce c++.atl c++.beta c++.chat c++.command-line c++.dos c++.dos.16-bits c++.dos.32-bits c++.idde c++.mfc c++.rtl c++.stl c++.stl.hp c++.stl.port c++.stl.sgi c++.stlsoft c++.windows c++.windows.16-bits c++.windows.32-bits c++.wxwindows digitalmars.empire digitalmars.DMDScript |
D - named unittests
Hi,
I think unittests should have an optional naming feature like:
class A {
void doA() {
}
void doA(int b) {
}
}
class B : A {
void doA() {
}
void doB() {
}
}
unittest (A) {
}
unittest (A.doA) {
}
unittest (A.doA(int)) {
}
unittest (B) {
}
unittest (B.doA) {
}
unittest (B.doB) {
}
or something like that. Usually unittests are associated to classes,
methods, or individual functions, via naming schemes. With this possibility
any tool could extract named bits of tests from a module, and use it to
create automatic documentation, or just show it to the user. It would be
better than javadoc capabilities, a doc tool for D could include contracts
and unittests when showing the documentation of a class, method or function.
Another possibility would be allowing unittest declarations inside
functions as:
int sum(int left, int right) {
unittest {
assert(15 == sum(7 + 8));
}
return left + right;
}
or
int sum(int left, int right)
unittest {
assert(15 == sum(7 + 8));
} body {
return left + right;
}
Best regards,
Daniel Yokomiso.
"When you want to change the world, you don't see the dawn by getting up
early - you see it by not sleeping through the night."
Nov 25 2002
|