Sinn und Zweck: Ich hab eine Klasse, deren Ctor und CopyCtor private sind. Um dies zu testen, würd ich gerne ein Testszenario bauen, was mir diese Eigenschaften testet, ohne zur kompilierzeit einen compiler-fehler zu werfen.

Ein plumper aufruf würde natürlich zur compilezeit in die hose gehen und introspection kann c++ auch nicht, hab ich also schlechte karten?

Ich würde gerne wissen, ob es möglich ist, zur Laufzeit zu prüfen, ob ein Constructor aufgerufen werden kann.

Nein.

Seikilos schrieb:

...würd ich gerne ein Testszenario bauen, was mir diese Eigenschaften testet, ohne zur kompilierzeit einen compiler-fehler zu werfen.

Was unsinnig ist. Fehler die bereits zur Compilezeit abgefangen werden können, sollten das auch. Fehler die zur Laufzeit auftreten sind deutlich problematischer.

Natürlich will ich das testen, wenn ich Unit Tests schreibe und die logs jemand fremdes anguckt, soll er die Funktionalität der getesteten Unit erkennen können

Funktionalität der getesteten Unit erkennen können

Die Nicht-Sichtbarkeit des Konstruktors ist doch keine Funktionalität.

Ist mir schon klar, ich will auch nicht den Fehler in die Laufzeit bringen, sondern nur meine Möglichkeiten zur Laufzeit auswerten.

Wie soll dies gehen wenn es bereits in der Kompilierung abgefangen wird? Es ist weder sinnvoll noch machbar es in der Laufzeit auszuwerten.

Seikilos schrieb:

Aber stimmt schon, das ist ein Fall für Introspection und Reflection.

Was nicht von C++ abgedeckt wird (und das Fehlen auf der einen Seite ist ein Vorteil auf der anderen Seite - Ich finde es gut wenn einige Prüfungen in die Compilezeit verlagert werden. Alles was nicht vor der Laufzeit schon ausgemerzt wird, ist eine weitere Fehlerquelle).

Es kann sein (ich bin mir sogar relativ sicher) das du solche Testfälle als Templatetechniken umsetzen kannst => Die Auswertung erfolgt aber ebenso zur Compilezeit.

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

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.

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

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.

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

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

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.