www.digitalmars.com Home | Search | C & C++ | D | DMDScript | News Groups | index | prev | next
Archives

D Programming
D
D.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