ich habe folgendes Problem: Ich habe in einer Klasse (nennen wir sie ZCL_A) Änderungen zu machen, die in einer von n Klassen (ZCL_1, ZCL_2, etc.) zu Unit-Test-Fehlern führen. Das fällt aber nicht bzw zu spät auf, weil diese Klassen nicht mit im Transportauftrag stehen.
Jetzt denke ich mir folgendes: Wenn es in ZCL_A einen Unit-Test gäbe, der die Tests in ZCL_1, ZCL_2, ... ausführen würde, würde eine Freigabe des Transports von ZCL_A auf einen Fehler laufen. Dafür müsste der Unit-Test auf einen Fehler laufen, wenn einer der Unit-Tests der n Klassen auf einen Fehler läuft.
Alternativ könnte man ZCL_1, ZCL_2, etc. auch in den Transport mit aufnehmen, aber wenn ich daran denke, denke ich auch dran, deren Unit-Tests auszuführen.
Ich brauch was Idioten.... ähhh... Ralf-sicheres 😉
Ich hab deswegen angefangen meine Unit-Tests in abstrakten Klassen AUßERHALB der eigentlich zu testenden Klassen zu organisieren. Dadurch ist der "Rumpf" der in den Klassen verbleiben muss (SETUP, TEARDOWN, etc.) nur noch sehr klein und fällt bei einer Kopie bzw. Verwendung in einer anderen Klasse daher kaum ins Gewicht. So kann man dann die notwendigen Tests bei allen abhängigen Klassen ebenfall ohne viel Aufwand einbinden (... INHERITING FROM ... ).
Alternativ haben wir bei uns auf dem Entwicklungssystem auch einen täglich laufenden Job der alle vorhandenen Unit-Tests ausführt und das Ergebnis per Mail versendet. Das hilft zwar nicht für die Transportfreigabelogik aber zumindest sieht man noch relativ zeitnah wenn man ein Upsi gebaut hat.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.