Hallo Spa\u00df Coder,<\/p>\n
in den letzten Artikeln Testautomatisierung<\/a>, Von Tests und Komponenten<\/a> sowie Kein Unit-Test wie jeder andere<\/a> haben wir euch hei\u00df darauf gemacht, euren Code automatisiert auf funktionale Richtigkeit hin zu \u00fcberpr\u00fcfen. In diesem Artikel m\u00f6chten wir euch ein paar Werkzeuge vorstellen, mit dessen Hilfe ihr euren Java-Code automatisiert testen k\u00f6nnt.<\/p>\n F\u00fcr Werkzeuge, die ihr im Umfeld von .Net verwenden k\u00f6nnt wird es noch einen eigenen Artikel geben.<\/p>\n Die hier verwendeten Beispiele testen eine Implementierung des Katas Russische Bauernmultiplikation<\/a> aus dem Fundus der Coding Dojos der CCD<\/a>.<\/p>\n Mit Hilfe von JUnit k\u00f6nnen wir unseren Code einfach automatisch testen, ohne die Anwendung selbst starten zu m\u00fcssen. Wir k\u00f6nnen Test-Code schreiben und darin die Methoden unserer Klasse aufrufen. JUnit f\u00fchrt diese Tests dann aus und bietet auch eine M\u00f6glichkeit, die Ergebnisse zu pr\u00fcfen.<\/p>\n Alle modernen IDEs binden JUnit ein. Die Tests lassen sich mit einem Klick starten und zeigen die Ergebnisse des Testaufrufs komfortabel an. So zeigt in aller Regel ein gr\u00fcner Balken, dass alle Tests erfolgreich durchlaufen wurden, ein roter, dass Tests fehlgeschlagen sind und ein gelber Balken zeigt an, dass Tests nicht ausgef\u00fchrt wurden. Bei fehlgeschlagenen Tests sehen wir dann, wo der Test fehlschl\u00e4gt und wir k\u00f6nnen uns sofort an die Behebung des Problems machen.<\/p>\n <\/p>\n Fangen wir mit einem einfachen Test an. Wir wollen testen, ob die Methode Mul<\/em> 1×1 rechnen kann. Wir erwarten, dass dabei das Ergebnis 1 herauskommt.<\/p>\n Seit JUnit 4 werden Tests durch Annotations gekennzeichnet. So leitet @Test<\/em> hier die Testmethode ein. Dadurch wei\u00df JUnit, dass dies ein ausf\u00fchrbarer Test ist. Funktioniert der Test, zeigt unsere IDE einen gr\u00fcnen Balken an. Schl\u00e4gt der Test hingegen fehl, wird der Balken rot und JUnit zeigt uns an, welcher Test fehlgeschlagen ist. Hier eine beispielhafte Ausgabe von JUnit, wenn die Methode Mul(1, 1) statt der erwarteten 1 eine 2 zur\u00fcck gibt:<\/p>\n junit.framework.AssertionFailedError:<\/span> Wir sehen also, dass der Aufruf in Zeile 12 der Test-Klasse RussischeBauernmultiplikationTest<\/em> zu einem Fehler f\u00fchrt.<\/p>\n Auch der Aufbau des Tests, wie wir ihn im Artikel\u00a0Von Tests und Komponenten<\/a> beschrieben haben ist hier erkennbar. Hier nochmal eine deutlichere Aufteilung am Beispiel des Tests 2×2 = 4:<\/p>\n Neben der zu testenden Klasse legen wir auch unser erwartetes Ergebnis in einer Variablen ab. Passend zum Parameternamen der assert-Methoden von JUnit nennen wir die Variable expected. <\/em>Dann rufen wir unsere zu testende Methode auf, also Mul <\/em>und speichern das Ergebnis in der Variable actual<\/em>. Zum Schluss pr\u00fcfen wir die Behauptung (assertion<\/em>), ob unsere Erwartung (expected<\/em>) mit dem tats\u00e4chlichen (actual<\/em>) Ergebnis \u00fcbereinstimmt.<\/p>\n Auf diese Weise lassen sich die meisten Methoden einfach testen.<\/p>\n <\/p>\n Die Bibliothek AssertJ erweitert JUnit um einen Aspekt, der unsere Unit-Tests lesbarer macht. So liest sich die \u00dcberpr\u00fcfung unserer Behauptung wie wir sie oben formuliert haben ein wenig holprig:<\/p>\n „Behaupte gleich, dass erwartet wie tats\u00e4chlich.“<\/p><\/blockquote>\n H\u00e4? Wer redet denn so einen Quatsch?<\/p>\n W\u00e4re es nicht sch\u00f6ner, wenn wir unsere Behauptung in etwa so formulieren k\u00f6nnten:<\/p>\n „Behaupte, dass tats\u00e4chlich gleich ist mit erwartet.“<\/p><\/blockquote>\n Das Klingt zugegebenerma\u00dfen immer noch ein wenig holprig. Versuchen wir das Ganze mal in Englisch:<\/p>\n „Assert that actual is equal to expected.“<\/p><\/blockquote>\n In unseren Ohren klingt das doch ganz gut. AssertJ hilft uns dabei, unsere Behauptungen genau so zu formulieren.<\/p>\n <\/p>\n Die beiden Beispiele von oben nun noch einmal mit Hilfe von AssertJ:<\/p>\n Das liest sich doch schon ganz gut. Verwenden wir nun noch die beiden Variablen, mal sehen, wie es dann aussieht:<\/p>\n Das liest sich doch sehr gut.<\/p>\n <\/p>\n Neben isEqualTo<\/em> bietet AssertJ noch eine ganze Menge anderer Methoden um unsere Behauptung zu pr\u00fcfen. Hier einmal ein Auszug:<\/p>\n Dar\u00fcber hinaus enth\u00e4lt AssertJ einige n\u00fctzliche Hilfsmethoden um Objekte in Listen zu pr\u00fcfen:<\/p>\n In diesem Fall wird die Liste persons<\/em> gefiltert, nach der id<\/em> mit dem Wert 0. Dann wird von der Person gepr\u00fcft, ob der name<\/em> der Person<\/em> „Hans“ lautet. Es erscheint auf den ersten Blick ein wenig kompliziert, ist aber recht einfach zu verstehen, wenn man sich mal ein wenig damit besch\u00e4ftigt hat.<\/p>\n Auch f\u00fcr den Umgang mit Daten (von Datum) liefert AssertJ ein paar n\u00fctzliche Methoden:<\/p>\n Wir sehen, dass wir ohne gro\u00dfen Aufwand unser Datum pr\u00fcfen k\u00f6nnen, teils mit recht komplexen Vergleichen, die hier leicht aufrufbar sind.<\/p>\n Was wir in diesem Beispiel zus\u00e4tzlich sehen ist eine best-practice zum Umgang mit ManagedExceptions in Unit-Tests. Statt einen Try-Catch-Block um den Aufruf von parse<\/em> zu machen (die Methode wirft eine ParseException<\/em>), schreiben wir an die Test-Methode einfach throws Exception<\/em>. Das h\u00e4lt unseren Test-Code lesbar, eine Fehlerbehandlung ben\u00f6tigen wir in der Regel nicht.<\/p>\n <\/p>\n W\u00e4hrend wir mit den vorgenannten Werkzeuge grunds\u00e4tzlich Unit-Tests schreiben k\u00f6nnen, hilft uns Mockito dabei unsere Tests von ggf. vorhandenen externen Einfl\u00fcssen zu isolieren. Falls euch jetzt nicht klar sein sollte, was wir damit meinen, lest noch einmal den Artikel Von Tests und Komponenten<\/a>. Hier wird auf die Notwendigkeit und die unterschiedlichen M\u00f6glichkeiten eingegangen.<\/p>\n <\/p>\n Mockito ist ein sehr m\u00e4chtiges Werkzeug. In diesem Rahmen m\u00f6chten wir euch die wichtigsten Anwendungsf\u00e4lle zur Isolation erl\u00e4utern, das Stubbing.<\/p>\n Wir rufen eine Methode auf und k\u00f6nnen mit Hilfe von Mockito festlegen, welchen Wert diese Methode zur\u00fcckgeben soll. Der folgende Test wird erfolgreich durchlaufen:<\/p>\n Die Methode Mul(1, 3)<\/em> gibt eigentlich den Wert 3 zur\u00fcck (1×3 = 3). Wir haben Mockito aber folgendes gesagt:<\/p>\n „Wenn die Methode Mul mit den Parametern 1 und 3 aufgerufen wird, gebe den Wert 5 zur\u00fcck.“<\/p><\/blockquote>\n Damit wir das \u00fcberhaupt tun k\u00f6nnen, m\u00fcssen wir zun\u00e4chst mit Hilfe von Mockito einen mock<\/em> der Klasse erstellen, dessen Methodenr\u00fcckgabe wir ver\u00e4ndern m\u00f6chten. In unserem obigen Fall handelt es sich dabei um ein Interface, es kann aber auch eine Klasse sein.<\/p>\n Wichtig zu wissen ist, dass bei einem Mock immer nur die Methoden einen Wert zur\u00fcckgeben, die wir auch konfiguriert haben. Erg\u00e4nzen wir noch folgenden Assert, wird der Test fehlschlagen:<\/p>\n org.junit.ComparisonFailure: <\/span> Die Methode Mul<\/em> haben wir nur f\u00fcr die Parameter (1, 3) konfiguriert. Rufen wir sie mit (1, 1) auf, wird der Initialwert des R\u00fcckgabetyps (in unserem Fall int<\/em>) zur\u00fcckgegeben (dieser ist bei int<\/em> 0).<\/p>\n <\/p>\n M\u00f6chten wir Methodenaufrufe mit beliebigen Parametern konfigurieren, m\u00fcssen wir sog. Matcher<\/em> verwenden:<\/p>\n Der hier verwendete Matcher<\/em> hei\u00dft anyInt()<\/em> und sorgt daf\u00fcr, dass immer dann der Wert 5 zur\u00fcckgegeben wird, wenn die Methode Mul<\/em> im ersten Parameter mit irgendeinen Integer aufgerufen wird. Der zweite Wert muss immer 3 sein. Auch hier wird ein Matcher verwendet, er hei\u00dft eq(…)<\/em> und greift dann, wenn der angegebene Wert genau gleich ist.<\/p>\n <\/p>\n Wichtig:<\/span> Wird in der Konfiguration bei einem der Parameter ein Matcher verwendet, dann muss auch in allen anderen Parametern ein Matcher verwendet werden!<\/strong><\/p>\n Folgender Code funktioniert so nicht, da wir den Matcher anyInt()<\/em> f\u00fcr den ersten Parameter verwenden, aber beim zweiten Parameter keinen Matcher angegeben haben:<\/p>\n Die Fehlermeldung die erscheint lautet:<\/p>\n org.mockito.exceptions.misusing.InvalidUseOfMatchersException:<\/span> In manchen F\u00e4llen lautet die Meldung bei zwei Parametern 3 matchers expected, 2 recorded<\/em>, auch wenn beide Parameter als Matcher angegeben wurden. In einem solchen Fall hat es uns geholfen auch den Wert bei thenReturn(…)<\/em> mit einem Matcher anzugeben.<\/p>\n <\/p>\n Die oben aufgef\u00fchrten Beispiele sind nat\u00fcrlich nicht sinnvoll, sie dienen nur dem Zweck, die Funktionsweise von Mockito leicht verst\u00e4ndlich zu beschreiben. Wenn wir das sut selbst mocken, testen wir den Code unserer Klasse den wir testen wollen nicht mehr. Hilfreich ist ein Mock aber immer dann, wenn wir unsere Klasse von Abh\u00e4ngigkeiten trennen wollen.<\/p>\n Nehmen wir als Beispiel den Test der Klasse „W\u00fcrfel“, dessen Methode „w\u00fcrfeln“ einen zuf\u00e4lligen Wert verwendet:<\/p>\n Im Grunde ist die Methode nicht testbar, da hier immer andere Ergebnisse herauskommen, wenn von der Klasse Random<\/em> die Methode nextInt()<\/em> aufgerufen wird. Mit Hilfe von Mockito k\u00f6nnen wir die Methode aber trotzdem testen:<\/p>\n Dieser Test funktioniert. In dem wir festlegen, dass beim Aufruf von nextInt()<\/em> immer ein fester Wert zur\u00fcckkommt, k\u00f6nnen wir testen, ob die Methode roll()<\/em> die Summe der Einzelw\u00fcrfe korrekt addiert.<\/p>\n <\/p>\n Wir setzen alle drei Werkzeuge vor allem im beruflichen Umfeld ein. Hier leisten sie uns gute Dienste und unterst\u00fctzen dabei, den Code abzusichern. JUnit und AssertJ nutzen wir eigentlich nur noch zusammen, weil der Test-Code dann einfach besser lesbar ist. Mockito hilft bei komplexeren Problemstellungen vor allem dabei, die Tests vom Dateisystem und der Datenbank zu trennen.<\/p>\n <\/p>\n Mit Hilfe der hier vorgestellten Werkzeuge und Beispiele solltet ihr in der Lage sein, euren Code elegant und automatisiert testen zu k\u00f6nnen. JUnit bildet die Basis aller Unit-Tests. AssertJ erweitert diese um n\u00fctzliche Funktionen und sinnvolle, einfach lesbare Syntax. Mockito hilft dabei, Tests von der umliegenden Infrastruktur zu trennen und auch Legacy-Code testbar zu machen ohne gleich die gesamte Code-Basis auf den Kopf stellen zu m\u00fcssen.<\/p>\n Wir hoffen, dass es euch hiernach leichter f\u00e4llt, euren sauberen Code auch funktional abzusichern.<\/p>\n Viel Spa\u00df beim Anwenden.<\/p>\n Eure Spa\u00df-Coder<\/p>\n <\/p>\n Weitere Infos zu den Bibliotheken:<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Hallo Spa\u00df Coder, in den letzten Artikeln Testautomatisierung, Von Tests und Komponenten sowie Kein Unit-Test wie jeder andere haben wir euch hei\u00df darauf gemacht, euren Code automatisiert auf funktionale Richtigkeit hin zu \u00fcberpr\u00fcfen. In diesem Artikel m\u00f6chten wir euch ein paar Werkzeuge vorstellen, mit dessen Hilfe ihr euren Java-Code automatisiert testen k\u00f6nnt. F\u00fcr Werkzeuge, die […]<\/p>\n","protected":false},"author":1,"featured_media":456,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[90],"tags":[69,77,85,84],"_links":{"self":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/453"}],"collection":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/comments?post=453"}],"version-history":[{"count":21,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/453\/revisions"}],"predecessor-version":[{"id":483,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/453\/revisions\/483"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media\/456"}],"wp:attachment":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media?parent=453"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/categories?post=453"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/tags?post=453"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}JUnit<\/h1>\n
Beispiele<\/h2>\n
@Test\r\npublic void testOneTimesOneIsOne() {\r\n\tRussischeBauernmultiplikation sut = new RussischeBauernmultiplikation();\r\n\tassertEquals(1, sut.Mul(1, 1));\r\n}<\/pre>\n
\nAls n\u00e4chstes erstellen wir eine Instanz unserer zu testenden Klasse RussischeBauernmultiplikation. <\/em>Wir haben uns angew\u00f6hnt die zu testende Variable sut<\/em> zu nennen, als Abk\u00fcrzung f\u00fcr S<\/strong>ubject U<\/strong>nder T<\/strong>est<\/em>. Dadurch erkennen wir auch bei komplexeren Testmethoden sofort, welche Klasse was wir eigentlich testen.
\nIn der letzten Zeile wird nun gepr\u00fcft, ob unsere Behauptung (englisch: Assertion) \u00fcberpr\u00fcft, dass 1×1 = 1 ist. Der erste Parameter der Methode assertEquals<\/em> ist dabei unser erwartetes Ergebnis (1) und der zweite Parameter der Methodenaufruf auf unserer Testklasse.<\/p>\n
\nExpected :1<\/span>
\nActual\u00a0 \u00a0\u00a0 :2<\/span>
\n\u00a0\u00a0\u00a0 at de.invidit.unittest.RussischeBauernmultiplikationTest.testOneTimesOneIsOne(RussischeBauernmultiplikationTest.java:12)<\/span><\/p><\/blockquote>\n@Test\r\npublic void testTwoTimesTwoIsFour() {\r\n \/\/ Initialisierung des Ausgangszustands\r\n RussischeBauernmultiplikation sut = new RussischeBauernmultiplikation();\r\n int expected = 4;\r\n\r\n \/\/ Aufruf der zu testenden Methode\r\n int actual = sut.Mul(2, 2);\r\n\r\n \/\/ Pr\u00fcfung des Ergebnisses\r\n assertEquals(expected, actual);\r\n}<\/pre>\nAssertJ<\/h1>\n
Beispiele<\/h2>\n
@Test\r\npublic void testOneTimesOneIsOne() {\r\n\tRussischeBauernmultiplikation sut = new RussischeBauernmultiplikation();\r\n\tassertThat(sut.Mul(1, 1)).isEqualTo(1);\r\n}<\/pre>\n@Test\r\npublic void testTwoTimesTwoIsFour() {\r\n\tRussischeBauernmultiplikation sut = new RussischeBauernmultiplikation();\r\n\tint expected = 4;\r\n\r\n\tint actual = sut.Mul(2, 2);\r\n\r\n\tassertThat(expected.isEqualTo(actual);\r\n}<\/pre>\nWeitere Features von AssertJ<\/h2>\n
\n
\n
\n
\n
\n
@Test\r\npublic void testFilterBeforeAssertionWithAssertJ() {\t\r\n\tList<Person> persons = new ArrayList<Person>();\r\n\tpersons.add(new Person(0, \"Hans\"));\r\n\tpersons.add(new Person(1, \"Max\"));\r\n\r\n\tassertThat(filter(persons).with(\"id\").equalsTo(0).get())\r\n\t\t\t.extracting(\"name\")\r\n\t\t\t.containsExactly(\"Hans\");\r\n\t\t\t\t\t\t\r\n}<\/pre>\n@Test\r\npublic void testDatesWithAssertJ() throws Exception {\t\t\r\n\tDate actual = new Date(1425078000000l);\t\t\r\n\t\r\n\tDate expected = new SimpleDateFormat(\"dd.MM.yyyy\").parse(\"28.02.2015\");\r\n\tAssert.assertEquals(expected, actual);\r\n\t\t\t\t\r\n\tassertThat(actual).isEqualTo(\"2015-02-28\");\t\t\r\n\tassertThat(actual).isEqualToIgnoringHours(\"2015-02-28\");\r\n\t\t\r\n\tassertThat(actual).hasTime(1425078000000l);\r\n\tassertThat(actual).isBefore(\"2015-03-01\");\r\n\tassertThat(actual).isBeforeOrEqualsTo(\"2015-02-28\");\r\n\tassertThat(actual).isBetween(\"2015-02-01\", \"2015-03-31\");\r\n\tassertThat(actual).isInThePast();\r\n}<\/pre>\nMockito<\/h1>\n
Beispiele<\/h2>\n
@Test\r\npublic void testMockitoSimpleWhenThenReturn() {\r\n\tMultiplikation mock = Mockito.mock(Multiplikation.class);\r\n\r\n\tMockito.when(mock.Mul(1, 3)).thenReturn(5);\r\n\r\n\tassertThat(mock.Mul(1, 3)).isEqualTo(5);\r\n}<\/pre>\nassertThat(mock.Mul(2, 3)).isEqualTo(6);<\/pre>\n
\nExpected :6<\/span>
\nActual\u00a0 \u00a0\u00a0 :0<\/span><\/p><\/blockquote>\nMatcher<\/h2>\n
Mockito.when(mock.Mul(Mockito.anyInt(), Mockito.eq(3))).thenReturn(5);\r\n\r\nassertThat(mock.Mul(2, 3)).isEqualTo(5);\r\nassertThat(mock.Mul(3, 3)).isEqualTo(5);\r\n<\/pre>\n
Mockito.when(mock.Mul(Mockito.anyInt(), 3)).thenReturn(0);\r\n\r\nassertThat(mock.Mul(1, 3)).isEqualTo(0);\r\n<\/pre>\n
\nInvalid use of argument matchers!<\/span>
\n2 matchers expected, 1 recorded:<\/span>
\n-> at de.invidit.unittest.ExampleMockTest.testMockitoSimpleWhenThenReturnWithMatcher(ExampleMockTest.java:33)<\/span><\/p><\/blockquote>\nEin „echtes“ Beispiel<\/h2>\n
public class Dice {\r\n private int noOfDices;\r\n private Random random;\r\n\r\n public Dice(int noOfDices, Random random) {\r\n this.noOfDices = noOfDices;\r\n this.random = random;\r\n }\r\n\r\n public int roll() {\r\n int sum = 0;\r\n for (int i = 0; i < noOfDices; i++) {\r\n sum += random.nextInt();\r\n }\r\n return sum;\r\n }\r\n}<\/pre>\n@Test\r\npublic void testRollWithTwoDicesReturnsCorrectSum() {\r\n\tRandom randmock = Mockito.mock(Random.class);\r\n\tMockito.when(randmock.nextInt()).thenReturn(4);\r\n\tDice sut = new Dice(2, randmock);\r\n\r\n\tint actual = sut.roll();\r\n\r\n\tassertThat(actual).isEqualTo(8);\r\n}<\/pre>\nUnsere Erfahrung mit\u00a0den Werkzeugen<\/h1>\n
Zusammenfassung<\/h1>\n
\n