SDA SE Wiki

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

User Tools

Site Tools


Differences

This shows you the differences between two versions of the page.

Link to this comparison view

research:jtransformer:testszuerst [2018/05/09 01:59] (current)
Line 1: Line 1:
 +//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 [[javadocschreiben|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|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|idresolver]]''​ ein entsprechendes [[http://​c2.com/​cgi/​wiki?​MockObject|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 ''​[[factgenerator|factgenerator]]''​s von den Tests des ''​[[idresolver|idresolver]]''​.
 +  * Zu jedem möglichen Knotentyp des ASTs muss mindestens ein Test vorhanden sein.
 +  * Zur Unterstützung dieser Tests entwickeln wir ein ''​[[testbed|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, [[http://​junit.sourceforge.net/​doc/​testinfected/​testing.htm|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