oder schreibt man einfach ne klasse mit ein paar methoden, die dann der zu testende klasse irgendwie testwerte gibt und auf das jeweils korrekte ergebnis prueft?

mfg,
julian

weiters wird dafür gesorgt dass bestimmte dinge nicht übersehen werden, z.b. wenn ein test mit einer exception abbricht.

was "a)" angeht: hier meine ich macros die sich z.b. darum kümmern dass, falls bestimmte voraussetzungen nicht erfüllt sind, bestimmte fehlermeldungen ausgegeben werden. z.b. wirst du nicht jedesmal einen ganzen try-catch block schreiben wollen, wenn du checken willst dass unter bestimmten voraussetzungen eine ganze bestimmte exception geworfen wird. oder eben keine exception geworfen wird.

wenn du z.b. boost.test verwendest kannst du einfach schreiben:

BOOST_AUTO_TEST_CASE(std_vector_at_throws_logic_error_when_out_of_range)
{
    std::vector<int> v;
    BOOST_CHECK_THROW(v.at(0), std::logic_error);
    v.push_back(123);
    BOOST_CHECK_NO_THROW(v.at(0));
    BOOST_CHECK_THROW(v.at(1), std::logic_error);
}

ohne boost.test müsste die funktion inetwa so aussehen:

unsigned int g_errors = 0;

void std_vector_at_throws_logic_error_when_out_of_range()
{
    std::vector<int> v;
    bool e = false;
    try {
        v.at(0);
        printf("error: no exception caught, expected std::logic_error.\n");
        g_errors++;
    } catch(std::logic_error const&) {
        // ok, do nothing
    } catch(...) {
        printf("error: unexpected exception.\n");
        g_errors++;
    }
    v.push_back(123);
    try {
        v.at(0);
    } catch(...) {
        printf("error: unexpected exception.\n");
        g_errors++;
    }
    try {
        v.at(1);
        printf("error: no exception caught, expected std::logic_error.\n");
        g_errors++;
    } catch(std::logic_error const&) {
        // ok, do nothing
    } catch(...) {
        printf("error: unexpected exception.\n");
        g_errors++;
    }
}

alleine der übersichtlichkeit halber würde ich also schon empfehlen ein test-framework zu verwenden. natürlich kann man sich die entsprechenden funktionen und macros auch selbst basteln, aber wieso das rad neu erfinden wenn andere sich schon die arbeit gemacht haben?

oder schreibt man einfach ne klasse mit ein paar methoden, die dann der zu testende klasse irgendwie testwerte gibt und auf das jeweils korrekte ergebnis prueft?

man schreibt üblicherweise test-funktionen, die möglichst die gesamten specs einer API prüfen. also quasi das ganze definierte verhalten einer API wird geprüft. wenn man die einzelnen tests auch noch ein wenig kommentiert hat man so schon eine ganz brauchbare dokumentation, was ein angenehmer nebeneffekt ist.
vor allem kann man die tests einfach laufen lassen, und damit schnell sicher sein dass das in den tests dokumentierte verhalten auch der wirklichkeit entspricht.

mfg,
julian

class ABC {
    public:
        static bool testYourself();
};

int main() {
    assert( ABC::testYourself() );
}

Sollte eher die Klasse sich selbst prüfen (soweit das autonom möglich ist), oder sollte von außen gegen das spezifizierte Verhalten getestet werden?

edit: Ok, wo ich mir das nochmal durchlese, es wird wahrscheinlich das letztere sein; vor allem auch, weil ja ein externer Mensch (=nicht-der-Entwerfer-des-zu-testenden-Objektes) die Tests schreiben kann, der wäre weniger "betriebsblind". Trotzdem würde mich ein kurzes Statement noch interessieren