4. Wahl eines Unittestingframeworks

Wahl eines Unittestingframeworks

  • ?

    Ich bin auf der Suche nach einem geeigneten Unittesting-Framework, das ich unter dem BDS 2006 verwenden kann.
    Vor der Installation von CppUnit bin ich zurückgeschreckt, das Boost-Testingframework habe ich nicht zum laufen bekommen. Beide sind eher auf den Visual-Studio-Compiler zugeschnitten.
    Kennt jemand eine C++-Builder-spezifische Anleitung für eine der genannten Lösungen oder kann ein anderes Framework empfehlen?

    0
  • B

    Wie wärs, wenn du auf den BCB2007 updatetest. Da ist ein Unittestframework dabei.

    0
  • ?

    Diese Option besteht leider nicht. Ich habe nun das Minimal-Framework QUnit gefunden. Mit einer kleinen Änderung konnte ich es mit dem C++ Builder kompilieren. Wie brauchbar es sein wird, wird sich zeigen. Wer weitere Vorschläge hat, möge sie äußern.

    0
  • B

    Was für Probleme hattest du denn mit der boost-Version?

    0
  • A

    Hallo,

    wir hatten auch CppUnit zum Laufen gebracht.
    Im Grunde gar nicht so schwer, wenn man's erst mal durchschaut hat.
    Es gibt auf der CodeGear-Seite auch eine Anleitung (ursprünglich
    für C++ Builder X), die man als Ausgangspunkt ganz gut verwenden
    kann.

    Gruß

    Alexander

    0
  • ?

    Nach zwei Stunden habe ich es nun mit Hilfe der genannten Anleitung (http://dn.codegear.com/article/32704) geschafft, CppUnit zu builden. Hier die Kurfassung für Leute, die per Suchmaschine mal hier landen sollten:

    • bcc-zip in rootverzeichnis entpacken
    • zeile 8 in makefile setzen (keine leerzeichen in pfad)
    • mksrclist.cpp als consolenanwendung builden (dazu den include <dir> zu <dir.h> ändern)
    • binary in root kopieren
    • in cppunit.mak in zeile 29 und 33 "-N" entfernen
    • zeile 45 durch folgende ersetzen:
      DYN_LINK = ilink32 -L"C:\Program Files\Borland\BDS\4.0\lib"

    Der letzte Punkt geht freilich eleganter...
    Ich fürchte, das ist alles gerade etwas kryptisch geraten, ergibt mit der verlinkten Anleitung dann aber Sinn.
    So, nun bin ich gespannt, ob Cppunit die Mühe wert war.
    Vielen Dank für den Tipp.

    0
  • H

    (Nicht über den Namenswechsel wundern...)
    Nach einigen Experimenten stehe ich vor neuen Problemen. Ich kann zwar Tests erzeugen und ausführen; will ich aber die Helpermacros verwenden, um die suite-Methode nicht von Hand schreiben zu müssen, bekomme ich zur Laufzeit Access Violations.
    Ich habe alles mit Beispielen aus verschiedenen Quellen abgeglichen. Das Verhalten ist recht undurchsichtig. Wenn ich mit CPPUNIT_TEST eine leere Testmethode hinzufüge, läuft alles problemlos. Eine zweite, ebenfalls leere Methode führt zum beschriebenen Fehler.

    Hier der Callstack:

    :76d4b08e kernel32.RaiseException + 0x58
:0031e9d2 CC3270.___raiseDebuggerException + 0x1a
:0031eaac CC3270.___raiseDebuggerException + 0xf4
:77171039 ntdll.RtlRaiseStatus + 0xb4
:7717100b ntdll.RtlRaiseStatus + 0x86
:77170e97 ntdll.KiUserExceptionDispatcher + 0xf
:00318d20 ; C:\Windows\system32\CC3270.DLL
:00318635 CC3270._free + 0xd
:002d1e6e CC3270.@$bdele$qpv + 0x1e
:00401E07 std::allocator<char>::deallocate(this=:0012FDD0, _Ptr=:00FD43CC,  =32)
:00401A82 std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Tidy(this=:0012FDC8, _Built=true, _Newsize=0)
:0040154D std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string<char, std::char_traits<char>, std::allocator<char> >(this=:0012FDC8)
:00401CF2 CppUnit::TestCaller<SimpleTest>::TestCaller<SimpleTest>(this=:00FD4374, name={ 4294967295, { "ÌCý\0èý\x12\0Â\t\x18\0$ÿ\x12\0", "SimpleTest::test2" }, 17, 31, {  } }, test=&SimpleTest::test2, fixture=:00FD43C0)
:004017B4 SimpleTest::addTestsToSuite(baseContext=:0012FEEC)
:00401337 SimpleTest::suite()
:004011E7 main(argc=1, argv=:01E03F10)
:0033cdc2 ; C:\Windows\system32\CC3270.DLL

    Die deallocate-Methode wird jeweils mit einem char-Pointer auf einen Methodennamen und einem Size-Parameter von 32 aufgerufen. Beim zweiten Mal schlägt der Ruf von delete darin fehl. Hier der Code:

    void deallocate(pointer _Ptr, size_type)
		{	// deallocate object at _Ptr, ignore size
		::operator delete(_Ptr);
		}

    Was mich wundert, ist, dass hier etwas, das im Debugger ganz wie ein C-String aussieht, mit delete und nicht mit delete [] deallokiert wird. Der Typ des Pointers wird per Template festgelegt. Ich bin nicht ganz sicher, ob die Mühe lohnt, mich hier durch die Eingeweide zu wühlen.

    Für einen Tipp wäre ich äußerst dankbar. Leider habe ich bisher niemanden gefunden, der ein ähnliches Problem beschreibt.

    0
Anmelden zum Antworten