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 .Net-Code automatisiert testen k\u00f6nnt. Wir setzen dabei wie immer C# als Sprache ein, die vorgestellten Werkzeuge funktionieren aber genauso gut mit VB.Net.<\/p>\n F\u00fcr Werkzeuge, die ihr im Umfeld von Java verwenden k\u00f6nnt lest den Artikel H\u00f6r mal wer da testet – Java Edition<\/a>.<\/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 <\/p>\n Mit Hilfe von NUnit 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. NUnit f\u00fchrt diese Tests dann aus und bietet auch eine M\u00f6glichkeit, die Ergebnisse zu pr\u00fcfen.<\/p>\n Das Visual Studio bindet NUnit mit Hilfe eines Plugins, die seit der Version 2013 auch in der kostenlosen Community Edition des VS verwendet werden k\u00f6nnen. Die Tests lassen sich dann mit einem Klick starten und zeigen die Ergebnisse des Testaufrufs komfortabel an. So zeigt 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 Fangen wir mit einem einfachen Test an. Wir wollen testen, ob die Methode Mul<\/em> 1\u00d71 rechnen kann. Wir erwarten, dass dabei das Ergebnis 1 herauskommt.<\/p>\n Das Attribut [Test]<\/em> kennzeichnet hier die Testmethode, wodurch NUnit diese Methode als ausf\u00fchrbaren Test erkennt. Als 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>ystem U<\/strong>nder T<\/strong>est<\/em> oder S<\/strong>ubject U<\/strong>nder T<\/strong>est (siehe auch Von Tests und Komponenten<\/a>)<\/em>. Dadurch erkennen wir auch bei komplexeren Testmethoden sofort, welche Klasse was wir eigentlich testen. Funktioniert der Test, zeigt NUnit einen gr\u00fcnen Balken an. Schl\u00e4gt der Test hingegen fehl, wird der Balken rot und NUnit zeigt uns an, welcher Test fehlgeschlagen ist. Hier eine beispielhafte Ausgabe von NUnit, wenn die Methode Mul(1, 1) statt der erwarteten 1 eine 2 zur\u00fcck gibt:<\/p>\n de.invidit.RussischeBauernmultiplikation.Test.RussischeBauernmultiplikationTests.OneTimesOneIsOne: Wir sehen also, dass der Aufruf in Zeile 15 der Test-Klasse RussischeBauernmultiplikationTests<\/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\u00d72 = 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 NUnit 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 Microsoft Unit Testing Framework funktioniert genauso wie NUnit und ist seit Version 2012 fester Bestandteil der kostenlosen Editionen des Visual Studios (VS Express und seit 2013 VS Community). Die Syntax unterscheidet sich von NUnit, die Einbindung in die IDE ist aber genauso gut (siehe oben bei der Beschreibung von NUnit).<\/p>\n F\u00fcr den Test mit dem Microsoft Unit Testing Framework werden eigene Attribute zur Kennzeichnung von Testklasse und -methoden verwendet.<\/p>\n So ersetzen wir einfach das Attribute [Test]<\/em> von NUnit durch [TestMethod]<\/em>. Dazu lege ich ein MS-Test Projekt an, womit auch die erforderlichen Verweise korrekt vorhanden sind. \u00dcber das Men\u00fc Test -> Run -> All Tests<\/em> lassen sich dann alle Test der Klasse ausf\u00fchren. Das Ergebnis wird im TestExplorer angezeigt.<\/p>\n <\/p>\n Die Bibliothek FluentAssertions erweitert das verwendete Testframework 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 \u201cBehaupte sind gleich, erwartet wie tats\u00e4chlich.\u201d<\/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 \u201cTats\u00e4chliches Ergebnis sollte gleich sein mit erwartetem Ergebnis.\u201d<\/p><\/blockquote>\n Das Klingt zugegebenerma\u00dfen immer noch ein wenig holprig. Versuchen wir das Ganze mal in Englisch:<\/p>\n \u201cActual should be expected.\u201d<\/p><\/blockquote>\n In unseren Ohren klingt das doch ganz gut. FluentAssertions hilft uns dabei, unsere Behauptungen genau so zu formulieren.<\/p>\n <\/p>\n Schauen wir uns dasselbe Beispiel wie oben an, n\u00e4mlich dass 1 x 1 = 1 ist (sein sollte).<\/p>\n Hier ist die Lesbarkeit schon h\u00f6her als oben beschrieben. Richtig spannend wird FluentAssertions in der Arbeit bestimmten Typen. Nachfolgend ein paar Ideen dazu:<\/p>\n Dar\u00fcber hinaus k\u00f6nnen\u00a0 Behauptungen auch kombiniert werden. Grunds\u00e4tzlich sollte immer nur ein Konzept innerhalb eines Tests gepr\u00fcft werden, aber FluentAssertions bietet auch die M\u00f6glichkeit Behauptungen zu verkn\u00fcpfen (AND<\/em> \/ OR<\/em>).<\/p>\n <\/p>\n W\u00e4hrend wir mit den vorgenannten Werkzeuge grunds\u00e4tzlich Unit-Tests schreiben k\u00f6nnen, hilft uns moq 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 moq 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 moq festlegen, welchen Wert diese Methode zur\u00fcckgeben soll. Der folgende Test wird erfolgreich durchlaufen:<\/p>\n Die Methode Mul(1, 3) <\/em>unserer Implementierung gibt den Wert 3 zur\u00fcck (1\u00d73 = 3). Wir haben moq auf Basis des Interfaces aber folgendes gesagt:<\/p>\n \u201cWenn die Methode Mul mit den Parametern 1 und 3 aufgerufen wird, gebe den Wert 5 zur\u00fcck.\u201d<\/p><\/blockquote>\n Damit wir das \u00fcberhaupt tun k\u00f6nnen, m\u00fcssen wir zun\u00e4chst mit Hilfe von moq 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 Test Name:\u00a0\u00a0 \u00a0testMockitoSimpleWhenThenReturn Result Message:\u00a0\u00a0 \u00a0Expected 1, but found 0.<\/p><\/blockquote>\n 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 Neben dem beschriebenen Stubbing wird beim Mocking nicht<\/strong> das eigentliche Testobjekt gepr\u00fcft, sondern ob die Aufrufe auf dem Mock-Objekt wie erwartet erfolgt sind.<\/p>\n Damit wird in unserem Beispiel die Methode Roll()<\/em> indirekt gepr\u00fcft. Dies kann dann sinnvoll sein, wenn gepr\u00fcft wird, ob der Aufruf einer Abh\u00e4ngigkeit mit korrekten Parametern erfolgt.<\/p>\n <\/p>\n M\u00f6chten wir Methodenaufrufe mit beliebigen Parametern konfigurieren, m\u00fcssen wir sog. Matcher<\/em> verwenden:<\/p>\n Die Klasse Moq.It<\/em> stellt verschiedene Matcher zur Verf\u00fcgung, welche zur Konfiguration von Stubs verwendet werden k\u00f6nnen.<\/p>\n Die oben aufgef\u00fchrten Beispiele sind nat\u00fcrlich nicht sinnvoll, sie dienen nur dem Zweck, die Funktionsweise von moq leicht verst\u00e4ndlich zu beschreiben. Hilfreich ist ein Mock immer dann, wenn wir unsere Klasse von Abh\u00e4ngigkeiten trennen wollen.<\/p>\n Nehmen wir als Beispiel den Test der Klasse \u201cW\u00fcrfel\u201d, dessen Methode \u201cw\u00fcrfeln\u201d 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 Next() <\/em>aufgerufen wird. Mit Hilfe von moq k\u00f6nnen wir die Methode aber trotzdem testen:<\/p>\n Dieser Test funktioniert. In dem wir festlegen, dass beim Aufruf von Next()<\/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 insbesondere Microsoft Unit Testing Framework und Fluent Assertions ein, wenn wir unsere .Net-Projekte entwickeln. Fr\u00fcher haben wir NUnit verwendet, da Microsoft Unit Testing Framework in den Express-Editionen des Visual Studios nicht zur Verf\u00fcgung stand. Da Fluent Assertion beide Frameworks unterst\u00fctzt und Microsoft Unit Testing Framework mittlerweile immer „an Bord“ ist, verwenden wir dies aus reiner Bequemlichkeit. Sie leisten uns gute Dienste und unterst\u00fctzen dabei, den Code abzusichern. Mit moq haben wir erst sehr wenig Erfahrung gesammelt und faktisch bislang in keinem Projekt eingesetzt. Wir haben unsere Mocks bislang immer manuell erstellt. Das werden wir aber in Zukunft sicher \u00e4ndern, da es ein gro\u00dfartiges Werkzeug ist.<\/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. NUnit und Microsoft Unit Testing Framework bilden die Basis aller Unit-Tests. Fluent Assertions erweitert – die bereits sehr elegante Schreibweise von NUnit seit Version 2.4 (Constraint-Based Assert Model) – und Microsoft Unit Testing Framework um n\u00fctzliche Funktionen und sinnvolle, einfach lesbare Syntax. moq 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 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 .Net-Code automatisiert testen k\u00f6nnt. Wir setzen dabei […]<\/p>\n","protected":false},"author":2,"featured_media":457,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[90],"tags":[29,87,69,77,75,85,84],"_links":{"self":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/459"}],"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\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/comments?post=459"}],"version-history":[{"count":27,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/459\/revisions"}],"predecessor-version":[{"id":504,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/459\/revisions\/504"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media\/457"}],"wp:attachment":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media?parent=459"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/categories?post=459"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/tags?post=459"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}NUnit<\/h1>\n
Beispiele:<\/h2>\n
[Test]\r\npublic void OneTimesOneIsOne()\r\n{\r\n IMultiplikation sut = new RussischeBauernmultiplikation();\r\n Assert.AreEqual(1, sut.Mul(1, 1));\r\n}<\/pre>\n
\nIn der letzten Zeile wird nun gepr\u00fcft, durch unsere Behauptung (englisch: Assertion), dass 1\u00d71 = 1 ist. Der erste Parameter der Methode AreEqual <\/em>ist dabei unser erwartetes Ergebnis (1) und der zweite Parameter das tats\u00e4chliche Ergebnis des Methodenaufrufs unserer Testklasse.<\/p>\n
\nExpected: 1
\nBut was:\u00a0 2
\nbei de.invidit.RussischeBauernmultiplikation.Test.RussischeBauernmultiplikationTests.OneTimesOneIsOne() in \\RussischeBauernmultiplikation.Test\\RussischeBauernmultiplikationNUnit\\RussischeBauernmultiplikationTests.cs:Zeile 15.<\/p><\/blockquote>\n[Test]\r\npublic void TwoTimesOneIsTwo()\r\n{\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 Assert.AreEqual(expected, actual);\r\n}<\/pre>\nMicrosoft Unit Testing Framework<\/h1>\n
Beispiele:<\/h2>\n
[TestMethod]\r\npublic void OneTimesOneIsOne()\r\n{\r\n\tIMultiplikation sut = new RussischeBauernmultiplikation();\r\n\tAssert.AreEqual(1, sut.Mul(1, 1));\r\n}<\/pre>\nFluent Assertions<\/h1>\n
Beispiele:<\/h2>\n
[TestMethod]\r\npublic void OneTimesOneIsOne()\r\n{\r\n IMultiplikation sut = new RussischeBauernmultiplikation();\r\n sut.Mul(1, 1).Should().Be(1);\r\n}<\/pre>\n\n
\n
\n
\n
\n
\n
[TestMethod]\r\npublic void StringWithFluentAssertions()\r\n{\r\n string testString = \"Dies ist ein Text\";\r\n testString.Should().Be(\"Dies ist ein Text\");\r\n testString.Should().NotBe(\"Dies ist kein Text\");\r\n testString.Should().BeEquivalentTo(\"DIES ist EIN Text\");\r\n\r\n testString.Should().Contain(\"t e\");\r\n testString.Should().NotContain(\"ist kein\");\r\n\r\n testString.Should().StartWith(\"Dies\");\r\n testString.Should().NotStartWith(\"Das\");\r\n testString.Should().StartWithEquivalent(\"dies\");\r\n\r\n testString.Should().EndWith(\"ein Text\");\r\n\r\n testString.Should().Be(\"Dies ist ein Text\").And.Contain(\"t e\");\r\n}<\/pre>\nmoq<\/h1>\n
Beispiele:<\/h2>\n
[TestMethod]\r\npublic void testMockitoSimpleWhenThenReturn()\r\n{\r\n var mock = new Mock<IMultiplikation>();\r\n mock.Setup(imp => imp.Mul(1, 3)).Returns(5);\r\n\r\n mock.Object.Mul(1, 3).Should().Be(5);\r\n}<\/pre>\nmock.Object.Mul(1, 1).Should().Be(1);<\/pre>\n
\nTest FullName:\u00a0\u00a0 \u00a0TestExamples.MoqExamples.testMockitoSimpleWhenThenReturn
\nTest Outcome:\u00a0\u00a0 \u00a0Failed
\nTest Duration:\u00a0\u00a0 \u00a00:00:00,1369741<\/p>\n[TestMethod]\r\npublic void testNextIsCalled()\r\n{\r\n var randMock = new Mock<Random>(); \r\n Dice sut = new Dice(2, randMock.Object);\r\n sut.Roll();\r\n\r\n randMock.Verify(imp => imp.Next());\r\n}<\/pre>\nMatcher<\/h2>\n
[TestMethod]\r\npublic void testMockitoSimpleWhenThenReturn()\r\n{\r\n var mock = new Mock<IMultiplikation>();\r\n mock.Setup(imp => imp.Mul(It.IsAny<int>(), 3)).Returns(5);\r\n\r\n mock.Object.Mul(1, 3).Should().Be(5);\r\n mock.Object.Mul(2, 3).Should().Be(5); \r\n}<\/pre>\n<\/h2>\n
Ein \u201cechtes\u201d Beispiel<\/h2>\n
public class Dice\r\n{\r\n private int noOfDices;\r\n private Random random;\r\n\r\n public Dice(int noOfDices, Random random)\r\n {\r\n this.noOfDices = noOfDices;\r\n this.random = random;\r\n }\r\n\r\n public int Roll()\r\n {\r\n int sum = 0;\r\n for (int i = 0; i < noOfDices; i++)\r\n {\r\n sum += random.Next();\r\n }\r\n return sum;\r\n }\r\n}<\/pre>\n[TestMethod]\r\npublic void testRollWithTwoDicesReturnsCorrectSum() {\r\n var randMock = new Mock<Random>();\r\n randMock.Setup(imp => imp.Next()).Returns(4);\r\n Dice sut = new Dice(2, randMock.Object);\r\n\r\n sut.Roll().Should().Be(8);\r\n}<\/pre>\nUnsere Erfahrung mit\u00a0den Werkzeugen<\/h1>\n
Zusammenfassung<\/h1>\n
\n