Ein Unit-Test ist eine automatisierte Prüfung, die eine einzelne Funktionseinheit eines Programms isoliert testet. Isoliert heißt: ohne Datenbank, ohne Netzwerk, ohne andere Programmteile. Der Test ruft eine Methode oder Funktion mit definierten Eingaben auf und prüft, ob das Ergebnis dem erwarteten Wert entspricht.
Gute Unit-Tests laufen automatisiert per Knopfdruck, jeder für sich, und prüfen jeweils genau eine Eigenschaft. Sie werden meist parallel zum Produktivcode geschrieben, teils sogar davor. Diese Reihenfolge nennt sich testgetriebene Entwicklung und zwingt den Entwickler, sich vor der Implementierung Gedanken über das gewünschte Verhalten zu machen. Der eigentliche Nutzen zeigt sich später: Wer eine Funktion umbaut, merkt sofort, wenn er dabei etwas kaputt gemacht hat. Ohne diese Tests bleibt "kaputt gemacht" oft bis zum nächsten Kundenanruf unentdeckt. Ein Unit-Test, der fehlschlägt, sollte außerdem sofort zeigen, welche einzelne Funktion betroffen ist, statt den Entwickler auf Fehlersuche durch die ganze Anwendung zu schicken. Fehlen solche Tests, verlagert sich die Prüfung meist auf den manuellen Klicktest durch einen Menschen, der zwar irgendwie funktioniert, aber jedes Mal von Neuem gemacht werden muss.
In der SAP-Business-One-Entwicklung tauchen Unit-Tests seltener auf als in klassischer Web-Entwicklung, weil viel Logik in Formular-Events statt in isolierten Funktionen steckt.
Abgrenzung
Ein Unit-Test prüft eine einzelne Einheit isoliert. Ein Integrationstest prüft, ob mehrere Einheiten korrekt zusammenspielen, etwa eine Funktion zusammen mit der echten Datenbank. Ein End-to-End-Test geht noch weiter und prüft den kompletten Ablauf aus Anwendersicht, von der Eingabemaske bis zum gespeicherten Beleg. Alle drei Testarten ergänzen sich. Wer nur Unit-Tests schreibt, hat viele geprüfte Einzelteile und trotzdem keine Garantie, dass sie zusammen funktionieren. Ein sauberer Satz aus allen drei Ebenen bleibt trotzdem die Ausnahme, nicht die Regel.
SAP B1 10.0 FP2608: Service Layer KI als transaktionalen Schicht
Process Reward Models: Warum ein richtiges Ergebnis noch keinen richtigen Weg beweist
Test-Time Compute Scaling: Warum ein kleineres KI-Modell am Ende gewinnen kann — und was der Lieferantenvergleich in SAP Business One damit zu tun hat
RLHF und Reward-Modelle: KI-Hype oder was der Genehmigungsprozess in SAP Business One damit zu tun hat
KI – Antworten aus SAP Business One – ohne SQL, ohne IT-Ticket
