SDA SE Wiki

Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

User Tools

Site Tools


Nachdem wir in der ersten Woche erfolgreich unsere erste Geschichte realisiert haben, erhöhen wir nun die Qualität unserer Codes. Die vollständige Abdeckung unseres Codes mit Unit-Tests ist dabei unser erklärtes Ziel.

Ein paar Notizen dazu, wie es geht:

Checkliste zum Auffinden der nötigen Testfälle

  • Mindestens ein Test für jede public-Methode einer Klasse.
  • Alle dokumentierten Eigenschaften der Methode prüfen. Insbesondere:
    • Wenn unsere Methode ihre Vorbedingungen prüfen soll, dann testen wir, dass sie das auch tut.
    • Jede garantierte Nachbedingung überprüfen wir auch mit mindestens einmal.
    • Jede Exception, die von unserer Methode geworfen werden kann, muss auch mindestens einmal provoziert werden.
  • Teste bei Arrays auch null und leere Arrays.
  • Teste auch mit der abstraktesten Klasse, die laut Methodensignatur zulässig ist. (Oft Object).
  • Prüfe Methoden mit Randwerten und mittleren Werte in jeder Kombination. Denke kombinatorisch! (Wenn unserer Methode z.B. zwei Parameter hat, ist es sinnvoll Aufrufe mit den Parameterkombinationen (min1, min2), (min1, mittel2), (min1, max2), (mittel1, min2), (mittel1, mittel2), (mittel1, max2), (max1, min2), (max1, mittel2), (max1, max2))

Tests für den ''[[factgenerator|factgenerator]]''

Der Kern unserer Software ist in der Klasse factgenerator zu finden. Hier wird Java-Code in Prolog-Fakten übersetzt. Diese Übersetzung muss natürlich so zuverlässig und vollständig sein, wie irgend möglich. Dazu ein paar Notizen:

  • Typischerweise wird ein Test ein Stück Java-Code nehmen, es in Prolog-Fakten übersetzen und überprüfen, ob das Ergebnis den korrekt ist.
  • Die Überprüfung der Prolog-Fakten ist sicher einfacher zu realisieren, wenn wir statt des idresolver ein entsprechendes Mock Object (dt.: Attrappe) verwenden, d.h. eine einfachere und berechenbarere Klasse, die das gleiche Interface und ein ähnliches Verhalten bereitstellt. Dadurch entkoppeln wir auch unserer Tests des factgenerators von den Tests des idresolver.
  • Zu jedem möglichen Knotentyp des ASTs muss mindestens ein Test vorhanden sein.
  • Zur Unterstützung dieser Tests entwickeln wir ein testbed.

Wirkliches Test-First-Design

Wir versuchen nun den gleitenden Übergang zu wirklicher Test-First Entwicklung. Die goldene Regel lautet hier Programmiere nur dann, wenn ein Test rot zeigt.

Und der Rhythmus der dabei entsteht ist auf englisch wohlklingend durch

Test a little - code a little - test a little - code a little

beschrieben. Probiert's aus. Es heisst, Programmierer mögen sowas. Das hält uns dazu an, nur das zu programmieren, was notwendig ist. Durch möglichst vollständige Tests, vermeiden wir, dass unbeabsichtigte Seiteneffekte unentdeckt bleiben. Das ist macht uns das umfassende Refactorieren unserers Codes einfacher, weil wir automatisch überprüfen können, dass wir das gewünschte Verhalten nicht verändert haben.

research/jtransformer/testszuerst.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2019