Automatisiertes Testen und Implementieren von UML-Diagrammen

Re: Automatisiertes Testen und Implementieren von UML-Diagra

Moin,

zur ersten Frage: Jeder, für den Softwarequalität kein Fremdwort ist. Es gibt Bereiche (z. B. Arzneimittelrecht) wo Validierung (sprich: geordnetes, dokumentiertes Testen) gesetzliche Voraussetzung ist.

Meine Lieblingszitate hierzu: "Jeder Schokoriegel ist besser getestet als Ihre unternehmenskritische Software" und "Würdet ihr eure XXX so professionell bauen wie euer SAP mit unternehmenskritischer Software, wäre der Laden hier längst pleite" (mit XXX = Produkt des Kunden).

Zum Aufwand: Es ist deutlich weniger aufwendig, als die Methode oder die Anwendung mit allen relevanten Fällen mit F8 zu testen. Zumal man einen Unit-Test jederzeit auf Knopfdruck wiederholen kann. Ein "Ausprobieren" ist kein Test, sondern setzt eine Testmatrix voraus, die bestimmt, welche verschiedenen relevanten Testfälle es überhaupt gibt.

Unterschätzen darf man es aber auch nicht, weil man natürlich alles mocken muss, was außerhalb der Methode liegt. Und: Ein integrativer Test der Anwendung ist etwas anderes als ein Unit-Test und durch diesen nicht zu ersetzen.

Zu der Sache mit den Klassendiagrammen: Nein, eine solche Funktion gibt es im SAP nicht. Wir entwickeln hier zumeist nach Scrum-Technik, da weiß man vorher gar nicht so genau, wie es letztlich implementiert wird. UML Klassendiagramme verwenden wir eher zur Dokumentation als zum Entwurf. Ich glaube auch nicht, dass bei großen Projekten jemand die Diagramme zeichnet, ehe er anfängt zu codieren.


Ralf

Re: Automatisiertes Testen und Implementieren von UML-Diagra

SaskuAc hat geschrieben:Unit Tests sind vergleichsweise schnell erstellt. in der Theorie sogar innerhalb von ein paar Sekunden ( Codevorlagen, dann geht das wie vom schnürchen ).

Das halte ich in vielen Fällen für übertrieben kurz, wenn man es richtig macht. Sprich: Wenn man alle Abhängigkeiten um die Methode herum mockt. Dann ist das schon aufwendiger.

Die Aussage ist richtig, wenn man eine Buchungsmethode für einen Beispielbeleg durchlaufen lässt und auf der DB prüft, ob die Daten auch so ankommen, wie geplant. Dann ist man aber systemabhängig und man führt Änderungen auf der Datenbank herbei. Beides ist unerwünscht.

In Wahrheit darf die Methode im Testfalle nicht auf die DB schreiben => man muss also zumindest den DB-Zugriff mocken.


Ralf

Re: Automatisiertes Testen und Implementieren von UML-Diagra

Hallo,

das kommt auf den Kunden an. Bei meinem letzten Kunden (Logistikkonzern in HH) war das sehr erwünscht, in meinem aktuellen Projekt (Arzneimittelbranche in HH) bin ich insbesondere, WEIL ich Unit-Test-Erfahrung habe. Dort unterliegen wir der Validierungspflicht, was umfangreiche Tests vorschreibt - dies wollen wir durch umfangreiche Testtools unterstützen. Das hat zwar mit Unit-Tests nur am Rande zu tun (weil wir Prozess-Schritte testen, nicht Methoden), aber Unit-Tests schreiben wir auch, weil wir sehr komplexe Klassen haben. Wenn da einer was ändert und nicht weiß, was er tut, macht er sie kaputt.

Bei vorherigen Kunden war es sehr schwierig, weil immer das Kostenargument kommt. Ich war ein paar Jahre bei einem Anlagenbauer in Hessen. Teilweise habe ich da Tests in der Freizeit geschrieben, weil ICH die haben wollte. Teilweise hab ich die geschrieben und abgerechnet, beanstandet wurde das nicht. Da war für mich nicht zu verstehen, dass das Produkt des Kunden sicherlich NICHT ungetestet rausgeht, man diese Qualitätsansprüche aber nicht auf unternehmenskritische Software übertragen.

Und das ist genau der Punkt, den ich nicht verstehe. Würde man ein Auto oder ein Fahrrad so bauen, wie SAP-Systeme programmiert werden, jeder Kunde würde einem einen Vogel zeigen.


Ralf