Ist es möglich zur Laufzeit zu testen, ob ein Constructor public ist?

Seikilos

knivil schrieb:

Im Kompilat existiert kein public mehr. Also kann man das auch nicht mehr testen.

Klar, mein Ziel war es zu testen, dass kein public ctor existiert.

compilezeit tests gehen absolut garnicht. das sind tests die in automatisierten regression tests laufen und am ende ein protokoll ausspucken. Ist ein bisschen blöd, wenn man einen von tausend tests nicht kompilieren kann und somit sein regression testing nicht ausführen kann

Christoph

Seikilos schrieb:

compilezeit tests gehen absolut garnicht. das sind tests die in automatisierten regression tests laufen und am ende ein protokoll ausspucken. Ist ein bisschen blöd, wenn man einen von tausend tests nicht kompilieren kann und somit sein regression testing nicht ausführen kann

Wenn das Kompilieren eines Tests fehlschlägt, ist der ganze Test fehlgeschlagen. Das könntest du protokollieren.

Simon2

Seikilos schrieb:

...
compilezeit tests gehen absolut garnicht. das sind tests die in automatisierten regression tests laufen und am ende ein protokoll ausspucken. Ist ein bisschen blöd, wenn man einen von tausend tests nicht kompilieren kann und somit sein regression testing nicht ausführen kann

hmmm, ich wüsste nicht, was dagegen spräche, in diese Tests einen einzelnen Test einzubauen, bei dem

#include <myAppClass.h>

int main() {
   myAppClass a;
   return 0;
}

compiliert wird und der als positiv gewertet wird, wenn der Compile mit einem bestimmten Fehler abbricht.
Das Compile-Ergebnis wird natürlich NICHT für die restlichen Tests verwendet (zumal ja nur ein Object erzeugt wird, wenn der Test fehlgeschlagen ist).

Insgesamt ist natürlich zu überlegen, wie die Ergebnisse der anderen Tests zu bewerten sind, wenn ein derartiger Fehler in der Klassenstruktur gefunden wird....

In bestimmten sehr speziellen Environments mag es natürlich sehr schwierig sein, auf der Testplattform zu compilieren ... aber für den Test braucht man keinen bestimmten Compiler, keine Libs und auch sonst eigentlich keine weitere Buildkomponente. Nur halt den Header, das TestPG und irgendeinen C++-Compiler.

Gruß,

Simon2.

Seikilos

@Christoph: Ja, manuell. Das ist aber nicht der Sinn von Regression-Tests die über Nacht laufen.
Ferner kann dann garnichts mehr kompilieren, wenn ich 100 Tests habe und einer dieser ctor test ist und dieser nicht kompiliert, werden die anderen 99 auch nicht mehr gestartet

Registrierter Troll

Seikilos schrieb:

Ferner kann dann garnichts mehr kompilieren, wenn ich 100 Tests habe und einer dieser ctor test ist und dieser nicht kompiliert, werden die anderen 99 auch nicht mehr gestartet

Das gleiche passiert dann auch bei Tippfehlern im Code - dafür willst du doch auch keine spezifischen Tests schreiben. Behandle einen falschen Konstruktor einfach genauso wie einen Tippfehler.

Simon2

Seikilos schrieb:

...
Ferner kann dann garnichts mehr kompilieren, wenn ich 100 Tests habe und einer dieser ctor test ist und dieser nicht kompiliert, werden die anderen 99 auch nicht mehr gestartet

Das habe ich immer noch nicht verstanden.
Ich stelle mir eine Testsuite ganz grob vereinfacht vor wie folgendes Skript:

# Testlauf.sh
test1.sh  > erg.log
test2.sh >> erg.log
test3.sh >> erg.log
test4.sh >> erg.log
test5.sh >> erg.log
test6.sh >> erg.log

und dann (kein Paradebeispiel für Skriptprogrammierung ... ich weiß )

# test3.sh
g++ -c myAppClass.DefCtorCheck.cpp -o /dev/null/myAppClass.DefCtorCheck.o > test3.log
CheckVal=`grep -c "no default constructor" test3.log`
if [ "$CheckVal" == "1" ]; then
   echo "OK"
   exit 0
fi

echo "FAILED"
exit 1

Warum sollten die anderen Tests nicht weiterlaufen?

Gruß,

Simon2.

Seikilos

Weil es eine Datei ist und portabel sein soll.

Niemand will hier bash oder batch scripte auf mehreren Systemen aktuell halten.

In meinem Szenario gibt es eine einzige Exe, die die Tests der Komponenten pro Projekt durchläuft

Simon2

OK,

dass es sich um unterschiedliche Testsysteme und -plattformen handelt, hatte ich bislang nicht verstanden.
Verstehe ich denn jetzt richtig, dass Du ein Testprogram in C++ schreibst, das dann für die unterschiedlichen Plattformen compiliert/gelinkt und dorthin ausgeliefert wird?

Dann müsste Dein Testprogramm die Schnittstellen der Klassen aber sowieso kennen, sowieso compiliert werden , ....

Nunja - langer Rede kurzer Sinn: Ich sehe weder die Notwendigkeit, sowas zur Laufzeit zu testen (vergleichbar mit den Tippfehlern im Code) noch kenne ich einen Mechanismus, der das (auch noch plattformübergreifend!) auch nur annähernd so zuverlässig prüfen kann wie ein Compiler.
(OK - wenn Du mit Debug-Info buildest, kann ich mir noch andere Toosl vorstellen, aber das willst Du besser nicht ).

Gruß,

Simon2.

Kann ich zur Compilezeit festellen ob ein ctor nicht public ist.
Also einen "Fehler" im Test erzeugen falls eine Klasse einen public ctor hat?

Michael E.

Ich kann mir nicht vorstellen, wie das gehen soll.