Softwaretechnologie, © Prof. Uwe Aßmann1
4) V alidation eines Pro grams mit Hilfe von Tests
Prof. Dr. rer. nat. Uwe Aßmann Institut für Software- und Multimediatechnik Lehrstuhl Softwaretechnologie Fakultät für Informatik TU Dresden Version 11-0.2, 16.04.111)
G ru nd la ge n
1)V al id at io n un d V er ifi ka tio n
2)V er tr äg e
3)Te st fä lle
2)R eg re ssi o nst es ts m it de m JU ni t- R ah m en w er k
3)E nt w ur fsm ust er in JU ni t
2Prof. Uwe Aßmann SoftwaretechnologieLi ter at ur
►O bl ig at or isch e Li te ra tu r
■Zuser Kap. 12 (ohne White-box tests) ■ST für Einsteiger Kap. 12 ■www.junit.org ■Junit 3.x arbeitet noch ohne Metadaten (@Annotationen) ●junit3.8.1/doc/cookstour/cookstour.htm. Schöne Einführung in Junit ●junit3.8.1/doc/faq/faq.htm Die FAQ (frequently asked questions) ■Achtung: JUnit 4 versteckt mehr Funktionalität in Metadaten ●http://junit.sourceforge.net/doc/cookbook/cookbook.htm ●http://junit.sourceforge.net/doc/faq/faq.htm ►W ei te rf üh re nd
■Andrew Hunt, David Thomas. The pragmatic programmer. Addison- Wesley. Deutsch: Der Pragmatische Programmierer. Hanser-Verlag. ■Uwe Vigenschow. Objektorientiertes Testen und Testautomatisierung in der Praxis. Konzepte, Techniken und Verfahren. dpunkt-Verlag, 2005.Softwaretechnologie, © Prof. Uwe Aßmann3
4.1) Grundlagen des Testens
4Prof. Uwe Aßmann SoftwaretechnologieG rundl agen
Validation: Überprüfung der Arbeitsprodukte bzgl. der Erfüllung der Spezifikationen und der Wünsche des Kunden Verifikation: Nachweis, daß ein Programm seine Spezifikation erfüllt Formale Verifikation: MathematischerBeweis desselben Testen:Überprüfen von Abläufen eines Programms unter bekannten Bedingungen, mit dem Ziel, Fehler zu finden Wichtig: Vollständigkeit!Te st ing show s the pre se nc e of bugs , but ne ve r the ir abs enc e (D ijk st ra ) V e ri fi ka ti on ze ig t, da ss da s P rogra mm se ine S p ez if ik at ion ri cht ig erf ül lt . V a lida ti on ze igt , da ss da s P rogra mm da s r ic h ti g e P robl em lös t.
Wikipedia: Verification and Validation: In engineering or a quality management system, "verification" is the act of reviewing, inspecting, testing, etc. to establish and document that a product, service, or system meets the regulatory, standard, or specification requirements. By contrast, validation refers to meeting the needs of the intended end-user or customer.
5Prof. Uwe Aßmann Softwaretechnologie
Test -Fi rst D evel opm ent
►G es et z 62 de s P ra gm at isch en P ro gr am m ie re rs : Te st en S ie fr ü hze iti g, hä uf ig u nd a ut om at isch
►W ei te re w ich tig e G ese tze d es pr ag m at isch en P ro gr am m ie re rs:
■Gesetz 49 (PP): Testen Sie Ihre Software, sonst tun es die Anwender! ■Gesetz 32 (PP): Ein totes Programm richtet weniger Schaden an als ein schrottreifes. 6Prof. Uwe Aßmann SoftwaretechnologieV -M odel l m it S tandar d- Test pr ozess (R echt er A st des V )
►Te st s w er de n bo tt om -u p er le di gt :
■Zuerst Verträge und Testfälle für die Klasse bilden ■Dann die einzelne Klasse testen ■Dann die Komponente ■Dann das System ■Dann der beta-Test ■Zum Schluss der Akzeptanztest (Abnahmetest) ►B itt e, a u ch so im P ra kt iku m vo rg eh en .
Analyse Grobentwurf Feinentwurf Implementierung
Abnahmetest Systemtest Integrationstest Komponententest Zusicherungen Methodentest Klassentest
Testfälle Testfälle Testfälle ■Gesetz 63 (PP): Das Programmieren ist nicht getan, bis alle Tests erfolgreich waren
Prof. Uwe Aßmann Softwaretechnologie
S of tw ar e hat ei ne test -get riebene A rchi tekt ur
►E in te st -ge tri ebe ne s S ys te m (t es t- dri ve n sy st em) b e st e ht a us ei ne m P ro gr am m ( S ys te m u nd er T e st , S U T ) m it se in er Te st um ge bu ng ( Te st -T re ib er )
►Te st s m üsse n vo r de m S yst em ei nsa tz er fo lg re ich b est an de n w er de n
►B ei sp ie l: TD D ( Te st -D rive n D eve lo pm en t)
►I. G . zu P ro gr am m en h at S of tw ar e ha t ei ne t est ge tr ie be ne A rch ite kt ur
KomparatorKomparator ProgrammProgramm Test-UmgebungError OkInputEingabedaten Ausgabedaten (Ist)
Ausgabedaten (Soll) Prof. Uwe Aßmann Softwaretechnologie
B ei spi el : W ie sc hr ei bt m an ei nen Test fü r ei ne M et hode?
►W ie t est et m an pa rse D ay( S tr in g d) ?
// A class for standard representation of dates. public class Date { public int day; public int month; public int year; public Date(String date) { day = parseDay(date); month = parseMonth(date); year = parseYear(date); } public int parseDay(String d) { if (d.matches(„\d\d\.[\s]\d\d\.[\s]\d\d\d\d“)) { // German numeric format day. month. Year return string2Int(d.substring(0,2)); } else { .. other formats... } } }// A class for standard representation of dates. public class Date { public int day; public int month; public int year; public Date(String date) { day = parseDay(date); month = parseMonth(date); year = parseYear(date); } public int parseDay(String d) { if (d.matches(„\d\d\.[\s]\d\d\.[\s]\d\d\d\d“)) { // German numeric format day. month. Year return string2Int(d.substring(0,2)); } else { .. other formats... } } }9Prof. Uwe Aßmann Softwaretechnologie
A nt w or t: Inner e C hecks und äusser e Test s
►Inne re C he ck s (V ert ra gs prüf unge n, c ont ra ct c he ck s) : in n er ha lb de r M et h od e w er de n Ü be rp rü fu n ge n ei ng e ba u t, d ie b e st im m te Zu si ch er un ge n er re ich en
■Innere Checks bestehen aus dem Überprüfen von Verträgen innerhalb von Methoden mit Hilfe von Probebeschicken von Methoden mit ausgewählten Parametern (Testdaten) ►Ä us se re T es ts : N ach A u fr uf e in e r M et ho de m it Te st da te n w er de n R el a tio ne n zw isc he n E in -, u n d A usg ab e pa ra m et er n so w ie d e m Zu st an d üb er pr üf t
■Black-box-Tests (schwarze Tests): bestehen aus ●dem Aufstellen von Testfällen (Testdaten für Eingabe-, Ausgabeparametern und Zustandsbelegungen) ●und deren Überprüfung nach Abarbeitung der Methode ●ohne Kenntnis der Implementierung der Methode ■White-box-Tests (weiße Tests): dto, ●aber mit Kenntnis über die Implementierung der Methode (z.B. Kenntnis der Steuerfluss-Pfade) 10Prof. Uwe Aßmann SoftwaretechnologieInner e C hecks: V er tr agspr üf ung für ei ne M et hode
►Inv ari ant en (i nv ari ant s) : B ed in g un g en ü be r de n Z ust an d (W er te vo n O bj ekt en u nd V ar ia bl en ), d ie im m er g ül tig si nd
►V orbe di ngung (pre condi ti on, A nna hme n, a ss umpt ions ):
■Zustand (Werte von Variablen), der vor Aufruf (bzw. Vor Ausführung der ersten Instruktion) gilt bzw gelten muss ■Typen von Parametern ■Werteeinschränkungen von Parametern ►N ac hb ed ingu ng (p os tc ond it ion , G ar an ti en, gua ra n te es , promi se s) :
■Zustand (Werte von Variablen), die nach Aufruf (bzw. nach Ausführung der letzten Instruktion) gültig sind ■Zuordnung von Werten von Eingabe- zu Ausgabeparametern (Ein- Ausgaberelation) Gesetz 31 (PP): Verwenden Sie Design by Contract (Vertragsprüfung), damit der Quelltext nicht mehr und nicht weniger tut, als er vorgibt. Gesetz 33 (PP): Verhindern Sie das Unmögliche mit Zusicherungen.Prof. Uwe Aßmann Softwaretechnologie
V er tr agspr üf ung für ei ne M et hode m it E xcept ions
►E in e fe hl ge sch la ge ne V e rt ra gsp rü fu ng ka n n e in e A usn ah m e (e xce pt io n) a usl öse n, m itt el s
throw-A nw ei su ng
public int parseDay(String d) { if (d.equals(„“) throw DateInvalid; if (d.size() < 10) throw DateTooShort; if (d.matches(„\d\d\.[\s]\d\d\.[\s]\d\d\d\d“)) { if (d.size() < 10) throw DateTooShort; // German numeric format day. month. Year int day = string2Int(d.substring(0,2)); if (day < 1 or day > 31) throw DayTooLarge; } else { .. other formats... } if (d.size() < 10) throw DateTooShort; if (day < 1 or day > 31) throw somethingWrong; return day; }public int parseDay(String d) { if (d.equals(„“) throw DateInvalid; if (d.size() < 10) throw DateTooShort; if (d.matches(„\d\d\.[\s]\d\d\.[\s]\d\d\d\d“)) { if (d.size() < 10) throw DateTooShort; // German numeric format day. month. Year int day = string2Int(d.substring(0,2)); if (day < 1 or day > 31) throw DayTooLarge; } else { .. other formats... } if (d.size() < 10) throw DateTooShort; if (day < 1 or day > 31) throw somethingWrong; return day; }Vorbedingung (precondition, assumption): D ist ein String D ist nicht leer
Invarianten (invariants): D ist mindestens 10 Zeichen lang (Datum plus Trenner) Nachbedingung (postcondition, guarantee): Ein int wird zurückgegeben Zwischen 1 und 31 Prof. Uwe Aßmann Softwaretechnologie
V er tr ag ei ner M et hode – P rüf en dur ch asser t
►assert(), e in e S ta n da rd m et h od e , b rich t d as P ro g ra m m b ei V er le tzu ng e in er V er tr ag sb ed in gu ng a b
►A ch tu ng : B ed in g un ge n m üs se n d u al z u de n B ed in g un g en d er vo rg en an nt en A usn ah m en f or m ul ie rt se in !
public int parseDay(String d) { assert(!d.equals(„“)); assert(d.size() >= 10)); if (d.matches(„\d\d\.[\s]\d\d\.[\s]\d\d\d\d“)) { assert(d.size() >= 10); // German numeric format day. month. Year int day = string2Int(d.substring(0,2)); assert(day >= 1 and day <= 31); } else { .. other formats... } assert(d.size() >= 10); assert(day >= 1 and day <= 31); return day; }public int parseDay(String d) { assert(!d.equals(„“)); assert(d.size() >= 10)); if (d.matches(„\d\d\.[\s]\d\d\.[\s]\d\d\d\d“)) { assert(d.size() >= 10); // German numeric format day. month. Year int day = string2Int(d.substring(0,2)); assert(day >= 1 and day <= 31); } else { .. other formats... } assert(d.size() >= 10); assert(day >= 1 and day <= 31); return day; }13Prof. Uwe Aßmann Softwaretechnologie
Ä uße re T est s: A uf sc hr ei ben vo n Test fäl le n in Test fal ltabel len
►E in Te st fa ll ta be lle se tzt fü r ei n e au fzu ru fe n de M et ho de E in -, A u sg ab ep a ra m et er , l oka le V ar ia bl en u nd O bj ekt at tr ib u te in B ezi eh un g.
■Gut-Fall (Positivtest): Testfall, der bestanden werden muss ■Fehlerfall (Negativtest): Testfall, der scheitern muss ■Ausnahmefall (Exception Test):Testfall, der in einer Exception (Ausnahme) des Programms enden muss, also einer kontrollierten Fehlersituation ►D ie T est fa llt ab el le sp ezi fizi er t al so e in en V er tr ag e xe m pl ar isch
►A u s je de r Ze ile d er T est fa llt ab e lle w ird e in a sse rt () -T est e rze u gt , d er na ch d em A uf ru f de r P ro ze du r au sg ef üh rt w ird
■Testet die Relation der Ein- und Ausgabeparameter, sowie der Objektattribute 14Prof. Uwe Aßmann SoftwaretechnologieB ei spi el : T est ei ner D at um skl asse
// A class for standard representation of dates. public class Date { public int day; public int month; public int year; public Date(String date) { day = parseDay(date); month = parseMonth(date); year = parseYear(date); } public int equals(Date d) { return day == d.day && year == d.year && month == d.month; } }// A class for standard representation of dates. public class Date { public int day; public int month; public int year; public Date(String date) { day = parseDay(date); month = parseMonth(date); year = parseYear(date); } public int equals(Date d) { return day == d.day && year == d.year && month == d.month; } }Prof. Uwe Aßmann Softwaretechnologie
B ei spi el ei ner zugehör igen Test fal ltabel le
►Te st fa llt ab el le n en th al te n Te st fä lle ( G ut -, Fe hl er- , A us na hme fä lle )
NrKlasseEingabedatenAusgabedatenErwarteter Status daymonthyear 1Gutfall1. Januar 2006112006Ok 2Gutfall05/12/20085122008Ok 3GutfallJanuary 23, 20172312017Ok 4Fehlerfall44, 2007Failure 5FehlerfallAup 23, 2005Failure 6AusnahmeMarch 44, 2007Exception Prof. Uwe Aßmann SoftwaretechnologieFI T T est fal ltabel len Fr am ew or k ht tp: //f it. c2. com
►FI T b ie te t e in e S pe zi fika tio n de r Te st fä lle in W or d od er E xce l
■Automatische Generierung von Junit-Testfällen ■Automatischer Feedback ►si eh e S of tw ar et ech no lo gi e- II , W S
http://fit.c2.com/files/WelcomeVisitors/example.gif17Prof. Uwe Aßmann Softwaretechnologie
public class DateTestCase { Date d1; Date d2; Date d3; public int testDate() { d1 = new Date(„1. Januar 2006“); d2 = new Date(„05/12/2008“); d3 = new Date(„January 23rd, 2009“); assert(d1.day == 1); assert(d1.month == 1); assert(d1.year == 2006); assert(d2.day == 5); assert(d2.month == 12); assert(d2.year == 2008); assert(d3.day == 23); assert(d3.month == 1); assert(d3.year == 2009); } } public class DateTestCase { Date d1; Date d2; Date d3; public int testDate() { d1 = new Date(„1. Januar 2006“); d2 = new Date(„05/12/2008“); d3 = new Date(„January 23rd, 2009“); assert(d1.day == 1); assert(d1.month == 1); assert(d1.year == 2006); assert(d2.day == 5); assert(d2.month == 12); assert(d2.year == 2008); assert(d3.day == 23); assert(d3.month == 1); assert(d3.year == 2009); } }
N euer T est fal l
►Te st fä lle w er de n in e in e Te st fa llkl asse g esch rie be n
■Die Testdaten befinden sich in einer Halterung (fixture) ■Eine Testfallklasse kann mehrere Testfälle aus der Testfalltabelle enthalten Halterung (fixture) 18Prof. Uwe Aßmann SoftwaretechnologieWi e w ähl e ich Test dat en aus?
►B est im m e di e E xt re mw ert e d er P ar am et er d er z u te st en d en M et ho de
■Nullwerte immer testen, z.B. 0 oder null ■Randwerte, z.B. 1.1., 31.12 ►B est im m e B ere ic hs ei ns chrä nk unge n
■Werte ausserhalb eines Zahlenbereichs ■negative Werte, wenn natürliche Zahlen im Spiel sind ►B est im m e Zus tä nde , i n d en e n si ch e in O bj ekt n ach e in er A nw e isu n g be fin de n m uss
►B est im m e Ä qui va le nzk la ss en vo n Te st da te n un d te st e nu r d ie R ep rä se nt an te n
►B est im m e al le W er te a lle r bool sc he n B edi ngunge n in d er M et ho de
■Raum aller SteuerflußbedingungenSoftwaretechnologie, © Prof. Uwe Aßmann19
4.2) Regressionstests mit dem JUnit- Rahmenwerk
20Prof. Uwe Aßmann SoftwaretechnologieTest fäl le
►Te st fa ll : H er be ifü hr en e in er b es tim m te n P ro g ra m m -S itu a tio n, m it be st im m te n Te st da te n
►Te st da te n : E in ga be , di e ei ne n ko nkr et en T est fa ll he rb ei fü hr t
►Te st da te ns at z : E in - un d A u sg ab ed at en , d ie zu e in e m T e st fa ll ge hö re n
►R egre ss ions te st : A ut om at isi er te r V e rg le ich vo n A usg a be da te n (g le ich er T est fä lle ) un te rsch ie dl ich er V er si on en d es P ro gr am m s.
■Da zu großen Systemen mehrere 10000 Testdatensätze gehören, ist ein automatischer Vergleich unerläßlich. ■Beispiel: Validierungssuiten von Übersetzern werden zusammen mit Regressionstest-Werkzeugen verkauft. Diese Werkzeuge wenden den Übersetzer systematisch auf alle Testdaten in der Validierungssuite an21Prof. Uwe Aßmann Softwaretechnologie
D as JU ni t R egr essi onst est -Fr am ew or k
►JU ni t
www.junit.orgist e in t ech n isch e s Ja va -Fr am ew or k fü r R eg re ssi on st est s, so w oh l f ür e in ze ln e K la sse n ( un it te st ) , a ls au ch fü r S yst em e
■Durchführung von Testläufen mit Testsuiten automatisiert ■Eclipse-Plugin erhältlich ■Mittlerweile für viele Sprachen nachgebaut ►Ju ni t 3 .8 .1 :
■88 Klassen mit 7227 Zeilen ■im Kern des Rahmenwerks: 10 Klassen (1101 Zeilen) ►Te st re su lta te :
■Failure (Zusicherung wird zur Laufzeit verletzt) ■Error (Unvorhergesehenes Ereignis, z.B. Absturz) ■Ok ►JU ni t- 4 ve rst eckt m eh r Fu n kt io n al itä t m it M e ta da te n (@A nn ot at io ne n ) un d ist w ese nt lich ko m pl exe r. E m pf eh lu ng : Le rn en S ie zu er st 3 .8 .1 !
22Prof. Uwe Aßmann SoftwaretechnologieK er n von JU ni t 3. 8. 1
run(TestResult)Test run(TestResult) runTest() setUp() tearDown()TestCase String name run(TestResult) add()
TestSuite
component TestResult setUp(); runTest(); tearDown(); MyTestCase .. init of test data runTest() setUp() tearDown() .. test methods testConversion() testInput()
TextTestResult UITestResult ... reason why failed ... test data
*
Prof. Uwe Aßmann Softwaretechnologie
E xkur s: E rkunde JU ni t 3. 8. x m it Javadoc
►A uf ga be :
■laden Sie die API-Dokumentation von JUnit mit einem Brauser Ihrer Wahl ■finden Sie die Aufgabe der Klassen TestResult, TestCase und TestSuite heraus ■Welche Aufgabe hat die Klasse Assert? Gesetz 68 (PP): Bauen Sie die Dokumentation ein, anstatt sie dranzuschrauben/home/ua1/Courses/ST1/Material/junit3.8.1/javadoc/index.html Prof. Uwe Aßmann Softwaretechnologie
B ei spi el : T est der D at um skl asse in JU ni t
// A class for standard representation of dates. public class Date { public int day; public int month; public int year; public Date(String date) { day = parseDay(date); month = parseMonth(date); year = parseYear(date); } public int equals(Date d) { return day == d.day && year == d.year && month == d.month; } }// A class for standard representation of dates. public class Date { public int day; public int month; public int year; public Date(String date) { day = parseDay(date); month = parseMonth(date); year = parseYear(date); } public int equals(Date d) { return day == d.day && year == d.year && month == d.month; } }25Prof. Uwe Aßmann Softwaretechnologie
public class DateTestCase extends TestCase { Date d1; Date d2; Date d3; protected int setUp() { d1 = new Date(„1. Januar 2006“); d2 = new Date(„01/01/2006“); d3 = new Date(„January 1st, 2006“); } public int testDate1() { assert(d1.equals(d2)); assert(d2.equals(d3)); assert(d3.equals(d1)); .... more to say here .... } public int testDate2() { .. more to say here .... } protected int tearDown() { .. .. } } public class DateTestCase extends TestCase { Date d1; Date d2; Date d3; protected int setUp() { d1 = new Date(„1. Januar 2006“); d2 = new Date(„01/01/2006“); d3 = new Date(„January 1st, 2006“); } public int testDate1() { assert(d1.equals(d2)); assert(d2.equals(d3)); assert(d3.equals(d1)); .... more to say here .... } public int testDate2() { .. more to say here .... } protected int tearDown() { .. .. } }
N euer T est fal l i n Juni t 3. 8. x
►Te st C ase s si nd M et ho de n, b eg in ne nd m it
test ►In iti al isi er un ge n de r H al te ru ng m it
setUp, A bb au m it
tearDown Halterung (fixture) 26Prof. Uwe Aßmann SoftwaretechnologieTest fal l al s K unde ei ner zu test enden K lasse
►Te st fa llkl asse n si nd a lso “ K un de nkl asse n ” vo n zu te st en de n K la sse n,
■die mittels äusserem Test deren Vorbedingungen, Invarianten und Nachbedingungen überprüfen ■Angewandt auf verschiedene Testdaten ►Te st fa llkl asse n im iti er en “ K un de n”
■unterliegen also dem Lebenszyklus eines objektorientierten Programms ■Aufbauphase (Testobjektallokation, Vernetzung) ■Arbeitsphase ■Rekonfigurationsphase ■Abbauphase27Prof. Uwe Aßmann Softwaretechnologie
public class TestApplication { ... TestCase tc = new DateTestCase(„testDate1“); TestResult tr = tc.run(); } public class TestApplication { ... TestCase tc = new DateTestCase(„testDate1“); TestResult tr = tc.run(); }
B enut zung von Test C ase
►V on E cl ip se a us: In e in er I D E w ie E cl ip se w er de n di e Te st fa ll- P ro ze du re n au to m at isch in sp izi er t un d ge st ar te t
►V on e in em Ja va -P ro gr am m a us:
■Ein Testfall wird nun erzeugt durch einen Konstruktor der Testfallklasse ■Der Konstruktor sucht die Methode des gegebenen Namens (“testDate1”) und bereitet sie zum Start vor ●mit Reflektion, d.h. Suche nach dem Methode in dem Klassenprototyp ■Die run() Methode startet den Testfall gegen die Halterung und gibt ein TestResult zurück 28Prof. Uwe Aßmann Softwaretechnologiepublic class TestApplication { ... TestCase tc = new DateTestCase(„testDate1“); TestCase tc2 = new DateTestCase(„testDate2“); TestSuite suite = new TestSuite(); suite.addTest(tc); suite.addTest(tc2); TestResult tr = suite.run(); // Nested test suites TestSuite subsuite = new TestSuite(); ... fill subsuite ... suite.addTest(subsuite); TestResult tr = suite.run(); }
Test sui ten
►E in e Te st su ite ist e in e K ol le kt io n vo n Te st fä lle n
►Te st S ui te s si nd ko m po si t
29Prof. Uwe Aßmann Softwaretechnologie
Test R unner G U I
►D ie K la ss en ju n it. a w tu i.T est R un n er , j u ni t.s w in gu i.T est R un ne r bi ld en ei nf ach G U Is, d ie T est re su lta te a nze ig en
►G ib t m a n e in em K on st ru kt o r ei ne s Te st fa lls ei ne K la sse m it, fi nd e t e r di e “t est *” -M et ho de n (d ie T est fa llm et ho de n) se lb st än di g
►D ie s ge sch ie ht m itt el s R ef le kt io n, d. h. A bs uch e n de r M et ho de nt ab el le n im K la sse np ro to typ en u nd M et ho de nsp ei ch er
public class TestApplication { public static Test doSuite() { // Abbreviation to create all TestCase objects // in a suite TestSuite suite = new TestSuite(DateTestCase.getClass()); } // Starte the GUI with the doSuite suite public static main () { junit.awtui.TestRunner.run(doSuite()); }public class TestApplication { public static Test doSuite() { // Abbreviation to create all TestCase objects // in a suite TestSuite suite = new TestSuite(DateTestCase.getClass()); } // Starte the GUI with the doSuite suite public static main () { junit.awtui.TestRunner.run(doSuite()); } Softwaretechnologie, © Prof. Uwe Aßmann304.2.2) Testläufe in Junit 4.X
Prof. Uwe Aßmann Softwaretechnologie
N euer T est fal l i n Juni t 4. X m it M et adat en- A nnot at ionen
►TestCases sind Methoden, annotiert mit @test, Initialisierung und Abräumen mit @before, @after ►Metadaten-Annotationen in Java entsprechen Stereotypen bzw Tagged Values in UML. Sie sind durch Annotationstypen typisiert public class DateTestCase /* no superclass */ { Date d1; Date d2; Date d3; @before protected int setUp() { d1 = new Date(„1. Januar 2006“); d2 = new Date(„01/01/2006“); d3 = new Date(„January 1st, 2006“); } @test public int compareDate1() { assert(d1.equals(d2)); assert(d2.equals(d3)); assert(d3.equals(d1)); .... more to say here .... } @test public int compareDate2() { .... more to say here .... } }public class DateTestCase /* no superclass */ { Date d1; Date d2; Date d3; @before protected int setUp() { d1 = new Date(„1. Januar 2006“); d2 = new Date(„01/01/2006“); d3 = new Date(„January 1st, 2006“); } @test public int compareDate1() { assert(d1.equals(d2)); assert(d2.equals(d3)); assert(d3.equals(d1)); .... more to say here .... } @test public int compareDate2() { .... more to say here .... } }Halterung (fixture) Prof. Uwe Aßmann Softwaretechnologie
public class TestApplication { ... DateTestCase tc = new DateTestCase(); Result tr = JUnitCore.run(tc.getClass()); } public class TestApplication { ... DateTestCase tc = new DateTestCase(); Result tr = JUnitCore.run(tc.getClass()); }
B enut zung von Test fal l-K lasse in 4. x
►V on d er K om m an do ze ile :
■java org.junit.runner.JUnitCore DateTestCase ►V on E cl ip se a us: In e in er I D E w ie E cl ip se w er de n di e Te st fa ll- P ro ze du re n au to m at isch in sp izi er t un d ge st ar te t
►V on e in em Ja va -P ro gr am m a us:
■Ein Testfall wird erzeugt durch einen Konstruktor der Testfallklasse ■Suche den Klassenprototyp der Testfallklasse ■Die run() Methode von JUnitCore startet alle enthaltenen Testfälle über den Klassenprotoypen ●Starten aller annotierten Initialisierungen, Testfallmethoden, Abräumer ■und gibt ein “Result”-Objekt zurück33Prof. Uwe Aßmann Softwaretechnologie
Juni t 4. X m it vi el en w ei ter en M et adat en- A nnot at ionen
►Viele weitere Test-Annotationstypen sind definiert public class DateTestCase { Date d1; @beforeClass protected int setUpAll() { // done before ALL tests in a class } @afterClass protected int tearDownAll() { // done before ALL tests in a class } @test(timeout=100,expected=IndexOutOfBoundException.class) public int compareDate2() { // test fails if takes longer than 50 msec // test fails if IndexOutOfBoundException is NOT thrown .... more to say here .... } }public class DateTestCase { Date d1; @beforeClass protected int setUpAll() { // done before ALL tests in a class } @afterClass protected int tearDownAll() { // done before ALL tests in a class } @test(timeout=100,expected=IndexOutOfBoundException.class) public int compareDate2() { // test fails if takes longer than 50 msec // test fails if IndexOutOfBoundException is NOT thrown .... more to say here .... } } Softwaretechnologie, © Prof. Uwe Aßmann344.3) Entwurfsmuster in JUnit
Prof. Uwe Aßmann Softwaretechnologie
W as ist ei n E nt w ur fsm ust er ?
►E in E nt w urf smus te r ist .. .
■Eine Beschreibung einer Standardlösung für ■Ein Standardentwurfsproblem ■in einem gewissen Kontext ►E in E nt w ur fsm ust er w ie de rv er w en de t be w äh rt e E nt w ur fsi nf or m at io n
■Ein Entwurfsmuster darf nicht neu, sondern muss wohlbewährt sein ►E n tw ur fs m u st er si n d ei n w ese nt ich es E n tw ur fsh ilf sm itt el a lle r In ge ni eu re
■Maschinenbau ■Elektrotechnik ■Architektur ►E nt w ur fsm ust er tr et en a uch in Fr am ew or ks w ie JU ni t a uf
Prof. Uwe Aßmann SoftwaretechnologieB ei spi el : E nt w ur fsm ust er in Juni t 3. x
►E nt w ur fsm ust er si nd sp ezi fisch e S ze na rie n vo n K la sse n
run(TestResult)Test run(TestResult) runTest() setUp() tearDown()TestCase String name run(TestResult) add()
TestSuite
Composite Composite
Leaf
component TestResult setUp(); runTest(); tearDown(); MyTestCase .. init of test data runTest() setUp() tearDown()
TextTestResult UITestResult ... reason why failed ... test dataTemplate Method
*
37Prof. Uwe Aßmann Softwaretechnologie
►
D ef in ie rt d as S ke le tt e in e s A lg o rit h m u ss es in e in e r S ch ab lo n en m et ho d e (t em pl at e m et ho d)
■Die Schablonenmethode ist konkret ►D el e g ie re T ei le zu a bst ra kt en H ak en m et ho de n ( ho ok m et ho ds)
■die von Unterklassen konkretisiert werden müssen ►V a rii e re V e rh al te n d er ab st ra kt en K la sse d u rch ve rsch ie de ne U nt er kl asse n
■Separation des “fixen” vom “variablen” Teil eines AlgorithmusE nt w ur fsm ust er T em pl at eM et hod
... primitiveOperation1(); ... primitiveOperation2(); ...AbstractClass TemplateMethod() primitiveOperation1() primitiveOperation2() ConcreteClass primitiveOperation1() primitiveOperation2() 38Prof. Uwe Aßmann Softwaretechnologie
B ei spi el T em pl at eM et hod: E in D at engener at or
►P ar am et er isi er un g ei ne s G en er at or s m it A nza hl u nd P ro du kt io n
■(Vergleiche mit TestCase aus JUnit) ... for (i = 0; i < howOften(); i++) { ... produceItem(); ...DataGenerator generate() howOften() produceItem() TestDataGenerator howOften() produceItem()
return 5;return 5; String word = grammar.recurse(); println(word);
- Grammar grammar;
Prof. Uwe Aßmann Softwaretechnologie
E nt w ur fsm ust er C om posi te
Component commonOperation() add(Component) remove(Component) getType(int) Composite commonOperation() add(Component) remove(Component) getType(int)Leaf commonOperation()
Client childObjects for all g in childObjects g.commonOperation()
}
Pseudo implementations*
►
