Testgetriebene Entwicklung mit Vulcan.NET und Visual Objects

Transkript

1 begrüßt Sie herzlich zum Vortrag auf der VODC 2006 Testgetriebene Entwicklung Dozent Michael Fischer Copyright 2006 Fischer & Consultants GmbH (F&C) Martinstrasse Dortmund Kontakt: Michael Fischer mifi@appfact.de Phone +49 (172) Fax +49 (941)

2 Inhalt 1.Grundlagen 2.Wahl der Waffen unter.net: NUnit vs. VSTS 3.Einführung in NUnit 4.Eine Klasse im Leben eines Test Driven Developers 5.VOUnit 6.Mehr Testverfahren 7.Integration von TDD in den Software- Entwicklungsprozess 8.Fragen und Diskussion Folie 2 von 27 Abstract: Test, Test, Test... Unit Tests mit Visual Objects und Vulcan.NET Test-driven Development lässt sich hübsch ins Deutsche übersetzen: Testgetriebene Entwicklung. Die im Zuge der agilen Software-Entwicklung populär gewordene Methode setzt das Schreiben von automatisierten Tests vor die eigentliche Codierung. Die Tests treiben das Design der zu schreibenden Software voran und führen so nicht nur zu soliderem Code sondern fördern auch ein verständlicheres Klassendesign. Während also der Rest der Software-Welt mit Werkzeugen wie JUnit, NUnit oder Visual Studio Team Services eine neue Qualität in die Programmierung bringt, hängt die VO-Gemeinde mangels äquivalenter Tools zurück. Mit Vulcan.NET, der ersten Xbase-Sprache für.net, ändert sich das Bild. Michael Fischer demonstriert live am Beispiel einer einfachen Aufgabenstellung, wie sich testgetriebene Entwicklung mit Vulcan.NET und NUnit im Alltag anfühlt, welchen Einfluss die Methode auf das Endergebnis hat und warum man süchtig danach werden kann, jeden Programmierertag mit grünen Ampeln zu beschließen. Und unter VO? Meinhard Schnoor-Matriciani hat für sein Team VOUnit entwickelt, eine einfache Implementierung von Unit Tests für Visual Objects. Im letzten Teil seiner Session stellt Michael Fischer VOUnit vor und zeigt, dass Sie auch für VO- Programme automatische Tests schreiben können. Der Sourcecode des Tools befindet sich auf der Konferenz-CD. 2

3 1. Grundlagen Testgetriebene Entwicklung Als testgetriebene Entwicklung (engl. test-driven development, Abkürzung TDD) bezeichnet man eine Agile Methode zur Softwareentwicklung, bei der die Programmierer Software-Tests vor den zu testenden Komponenten entwickeln. Populär geworden durch Kent Becks Buch über Extreme Programming (1999) Design-Methode und Bestandteil eines Softwareprozesses Modultest Modultests (engl. unit test) sind automatisiert ausführbare Codefragmente, die die öffentliche Schnittstelle einer Komponente (Klasse) verifizieren. Grey-Box-Test fokussiert auf eine Aussage (atomar), unabhängig von einander (isoliert) Folie 3 von 27 Agile Methoden sind Methoden zur Umsetzung eines Agilen Software- Entwicklungsprozesses wie z.b. des Extreme Programming. Die Agile Softwareentwicklung betont Werte, Prinzipien und Methoden gegenüber einer eventuell bürokratisch definierten Softwareentwicklung. Erst die Bewegung der agilen Prozesse hat die testgetriebene Entwicklung populär gemacht. TDD sollte immer im Kontext mit anderen agilen Methoden (Paarprogrammierung, Refactoring, fortlaufende Integration) gesehen werden. Der Grey-Box-Test besitzt sowohl Aspekte des White-Box-Tests als auch des Black-Box-Tests. Mit dem White-Box-Test hat er gemeinsam, dass er ebenfalls von den gleichen Entwicklern wie das zu testende System geschrieben wird. Mit dem Black-Box-Test teilt er sich anfänglich die Unkenntnis über die Interna des zu testenden Systems, weil der Test vor dem zu testenden System kommt. Integrationstests (z.b. von Anwendern postulierte Funktionstests) sind dagegen eine aufeinander abgestimmte Reihe von Einzeltests, die dazu dienen, verschiedene voneinander abhängige Komponenten eines komplexen Systems im Zusammenspiel miteinander zu testen. Die erstmals im gemeinsamen Kontext zu testenden Komponenten haben jeweils einen Unit- Test erfolgreich bestanden und sind für sich isoliert fehlerfrei funktionsfähig. Im Gegensatz zu Modultests werden Integrationstests meist manuell ausgeführt. Sie sind nicht Thema dieses Vortrages. 3

4 1. Grundlagen Test Framework Framework zur Ausführung automatisierter Tests. Besteht aus Klassen (und Attribute) zur Programmierung der Unit Tests Runner zur Testdurchführung Console und GUI Integration in Entwicklungsumgebung (optional) Der Console-Runner wird i.a. in einen übergeordneten Build-Prozess integriert. Folie 4 von 27 Historie SUnit für Smalltalk gilt als Mutter der xunit-systeme JUnit für Java (Erich Gamma und Kent Beck) NUnit für die.net Welt Bemerkenswerterweise sind alle drei Systeme Open Source und werden von SourceForge.NET gehostet. Implementierung Die Implementierung von xunit Frameworks in modernen Sprachen beruht heute auf diesen Sprachmerkmalen: Attribute (.NET) oder Annotations (Java) zur Kennzeichnung von Testfällen Dynamisches Laden von Libraries mit Testfall-Klassen in den Runner Reflection zur Analyse der Testfälle durch den Runner 4

5 1. Grundlagen Zyklus der testgetriebenen Entwicklung 1. Wähle den nächsten Test. Der Test soll einfach sein. 2. Schreibe den Test. Der Test muss fehlschlagen. 3. Sorge dafür, dass der Test funktioniert. Lass es grün leuchten! Schnell! 4. Räume den Code auf. Entferne doppelten Code, ändere Implementierungen wo notwendig, achte auf Codekonventionen. Folie 5 von 27 Man kann nicht alles testen. Nichts zu testen ist Selbstmord. Wie findet man die richtigen, die lohnenden Tests? Tests sind eine Wette. Man wettet entweder darauf, dass etwas funktioniert. Zeigt der Test das Gegenteil, ist nichts wichtiger, als den Test zum Laufen zu bringen. Oder man wettet darauf, dass etwas nicht funktioniert. Läuft der Test glatt durch, ist das fast noch beunruhigender, als der erste Fall. Hier muss untersucht werden, ob der Code intelligenter ist, als man dachte, oder ob man nur noch nicht den richtigen Test geschrieben hat. Mit der Zeit lernt man, die Tests zu schreiben, die sich auszahlen. Code Coverage Analysen (Testgradabdeckung) können dabei helfen, die richtige Menge an Tests zu finden. Sie haben jedoch nur begrenzten Aussagewert hinsichtlich der Testqualität. 5

6 1. Grundlagen Vorteile von TDD Wartbarkeit Aufgrund der Tests muss niemand Angst haben, durch Änderungen an einer Komponente (Refactoring) existierende Funktionalität zu brechen. Design Qualität Der Entwickler einer Komponente muss seine eigenen Klassen konsumieren, bevor er sie schreiben kann. Code Qualität Mit der Anzahl der Tests wächst die Qualität des Codes. Weniger Nebeneffekte Programmierer arbeiten die meiste Zeit an korrekten Systemen. Folie 6 von 27 Beck nennt als zusätzlichen Vorteil das Vertrauen des Entwicklers in seinen Code. Ein weiterer Vorteil ist die Dokumentationsfunktion, die der Testcode übernimmt. Guter, knapp kommentierter Testcode ersetzt jedes Quick Start- Handbuch einer Komponente. 6

7 1. Grundlagen Probleme von TDD Existierende Projekte keine Tests vorhanden ggf. fehlendes Test Framework unzureichende Trennung von GUI und funktionalem Code Ungeeignet für Anfänger Wie soll ich etwas testen, das noch nicht vorhanden ist? Schlechte Tests werden zu rosaroten Brillen. Isolation fällt schwer Abhängigkeit von externen Systemen (Schnittstellen, Datenbanken, Services) Unzureichende Tools für Datenbank-Projekte Tests von Server-side Business Logic sind ein Stiefkind der Testgemeinde Folie 7 von 27 Existierendes System ohne vorhandene Tests, fehlendes Test Framework und unzureichende Trennung zwischen GUI und funktionalem Code: so lassen sich praktisch alle Visual Objects Projekte beschreiben. Auf diese Situation geht das Kapitel zu VOUnit ein. Auf das Problem der Anfänger (gilt nicht nur für Programmieranfänger im Allgemeinen sondern auch für Anfänger bei Unit Tests) antwortet das Extreme Programming z.b. mit der Methode der Paarprogrammierung. Eine andere Antwort ist die Schulung von Entwicklern mit Hilfe von Test Patterns, wie sie z.b. Mark Clifton in seinem Artikel auf codeproject.com beschreibt. Externe Systeme können über Mock-Objekte simuliert werden. 7

8 2. NUnit vs. VSTS NUnit (+) Open Source, kostenlos (+) Ausgereift Angelehnt an andere xunit Implementierungen Erstes Release 2002 Version 2 zugeschnitten auf.net Framework (+) Offen VS 2003 VS 2005 VS Express Sharp Develop Mono (+) Geschaffen für TDD Add-Ons z.b. NCover für Code Coverage und TestDriven.NET für VS-Integration Folie 8 von 27 Dieser Vortrag beruht auf Version

9 2. NUnit vs. VSTS Visual Studio 2005 Team System (VSTS) (+) Enge Verzahnung mit anderen Funktionen des Team System IDE Integration, Testsgradabdeckung, Projektmanagement, etc. (+) Test Case Generierung (-) Nur Visual Studio 2005 Team Editionen, hohe Lizenzkosten VS 2005 Professional: 811,21 VS 2005 Team Developer: 5.586,21 (Zoschke, August 2006) Folie 9 von 27 Fazit Die meisten Teams sind mit einer Version von VS Standard oder Professional je Entwickler und NUnit gut gerüstet. Die mit Vulcan.NET kommende OEM- Version von Visual Studio reicht meines Erachtens nach nicht, da sie nicht die Integration von C# und VB.NET enthält. Die vielen Beispiele zur Programmierung mit.net, die auf den einschlägigen Internet-Portalen (z.b. codeproject.com oder gotdotnet.com) zu finden sind, können damit nicht direkt in VS geöffnet und ausgeführt werden. 9

10 3. Einführung in NUnit Schritte zum SimpleVulcanTest.prg Neue Vulcan.NET Klassenbibliothek Referenz zu nunit.framework hinzufügen sollte sich nach der Installation im GAC befinden Testklasse schreiben notwendige Attribute und Methoden kommen aus dem Framework danach Build der Assembly NUnit Projekt in der NUnit GUI anlegen Assembly dem Projekt hinzufügen Test kann sofort laufen NUnit Projekt der VS Solution hinzufügen beim ersten Aufruf die NUnit GUI als Default Program definieren Folie 10 von 27 Installation Die Installation von NUnit ist denkbar einfach: auf gehen, dort auf Download und die aktuelle Production Release herunterladen, am einfachsten das Windows installer package. Darauf achten, die Version für das.net Framework 2.0 zu nehmen, da Vulcan.NET nur unter dieser Version läuft. Einstellen der Class Library Bei der neuen Class Library sollte man die üblichen Schritte zur Konfiguration der Assembly gleich zu Beginn durchführen: AssemblyInfo definieren Default Namespace in den Properties setzen In diesem Fall Treat Warnings As Errors in den General Settings ausschalten 10

11 3. Einführung in NUnit Test Klasse Ergebnis im GUI Runner Using System Using NUnit.Framework [TestFixture]; Class SimpleVulcanTest Protected value1 As Int Protected value2 As Int [Setup]; Method Init() As Void Class SimpleVulcanTest value1 := 2 value2 := 3 Return [Test]; Public Method Add() As Void Class Simple Local result As Int result := value1 + value2 Assert.AreEqual(6, result, "Expected Failure.") Return Folie 11 von 27 Und jetzt? Lass es grün leuchten! Schnell! Übungsaufgabe: SimpleVulcanTest.prg Testmethode für Testmethode abarbeiten und nach jeder Methode die Tests erneut durchführen. 11

12 3. Einführung in NUnit Attribute TestFixture Kennzeichnet eine ganze Klasse als Testklasse Setup und TearDown Methoden werden vor und nach jeder Testmethode aufgerufen TestFixtureSetup und TestFixtureTearDown Methoden werden einmal vor und nach allen Testmethoden aufgerufen Test Kennzeichnet eine Methode als Test ExpectedException Zum Testen von erwarteten Ausnahmen (Exceptions) Weitere Attribute zur Steuerung der Testläufe Ignore, Platform, Category, Explicit Folie 12 von 27 12

13 3. Einführung in NUnit Die Klasse im Reflector Folie 13 von 27 Reflection Die NUnit Runner (GUI und Console) sind ein schönes Beispiel für die Verwendung von Reflection im.net Framework. Die Attribute an der Klasse und an den Methoden, die man hier sieht, steuern den NUnit Runner. Dieser durchsucht per Reflection die geladenen Assemblies nach Testfällen. So weiß der NUnit Runner, welche Klassen er instanzieren und welche Methoden er ausführen muss. 13

14 3. Einführung in NUnit Assertions Die statischen Methoden der Klasse Assert sind die wichtigsten Werkzeuge beim Schreiben von Testfällen. Equality Hat etwas den erwarteten Wert? AreEqual und AreNotEqual Condition Ist ein Objekt in einem erwarteten Zustand IsTrue, IsFalse, IsNull, IsNotNull, IsNaN, IsEmpty, IsNotEmpty Identity Referenzierenzwei Variablen auf dasselbe Objekt? AreSame, AreNotSame und Contains Folie 14 von 27 Alle Methoden haben zahlreiche Überladungen. 14

15 3. Einführung in NUnit Assertions Type Ist ein Objekt von einem bestimmten Typ? IsInstanceOf, IsNotInstanceOf, IsAssignableFrom, IsNotAssignableFrom Comparison Ist ein Objekt größer/kleiner als ein anderes? Greater und Less Folie 15 von 27 Neuerungen in der kommenden Version 2.4 vor allem bei den Assertions: CollectionAssert FileAssert Assert-Methoden 15

16 4. TDD Beispiel Aufgabe: Stack-Klasse test driven entwickeln Methoden und Eigenschaften der Klasse Push() Objekt von oben auf den Stack legen Pop() Objekt von oben wieder vom Stack nehmen und zurückgeben Top() Oberstes Objekt vom Stack zurückgeben aber auf dem Stack lassen IsEmpty true, wenn sich keine Objekte auf dem Stack befinden basiert auf Kapitel 2 des Buchs von Jim Newkirk und Alexei Vorontsov. Folie 16 von 27 Hört sich einfach an, oder? Aufgabe: Schreiben Sie eine kurze Liste der Tests, die Sie benötigen werden. 16

17 4. TDD Beispiel Inhalte der Beispielsession Trennung von Code und Testcode Getrennte Bibliotheken Testbibliothek referenziert NUnit.Framework und den eigentlichen Code Test-driven Design Der Code folgt dem Test, TDD ist eine agile Methode, keine nachträgliche Pflichtaufgabe! Das Ziel Alles ist grün Debugging von Bibliotheken mit Unit Tests Folie 17 von 27 Download des Buchkapitels zum Beispiel Die Session wurde von C# auf Vulcan.NET. Sie basiert auf Kapitel 2 des Buchs von Jim Newkirk und Alexei Vorontsov. Das Kapitel kann als PDF von heruntergeladen werden. Der Vulcan.NET Sourcecode liegt dieser Präsentation bei. 17

18 4. TDD Beispiel Debugging Der GUI Runner von NUnit eignet sich auch als Prozeß für das Debuggen von Code in Bibliotheken. NUnit GUI starten In Visual Studio: Debug, Attach to Process NUnit Prozeß auswählen Breakpoints im Sourcecode setzen Testmethode in NUnit laufen lassen Alternative ist das (für professionelle Entwickler) kostenpflichtige Tool TestDriven.NET Folie 18 von 27 18

19 5. VOUnit Probleme bei der Entwicklung eines Test Frameworks für Visual Objects Begrenzte Fähigkeiten der Sprache VO: Keine Attribute Wie Klassen als TestFixture kennzeichnen? Wie Methoden als Testmethoden kennzeichnen? Wie erwartete Exceptions signalisieren? Keine Interfaces siehe dazu den Vortrag von Meinhard Schnoor-Matriciani über Design Patterns mit VO und Vulcan.NET Eingeschränkte Reflection ClassList, MethodList etc. Folie 19 von 27 19

20 5. VOUnit TestFixture Alle Tests stehen in DLLs. Die DLLsmüssen folgende Funktion enthalten. Anhand dieser Funktion akzeptiert der Runner eine DLL als Testsuite. Die Testklassen müssen von BaseTest vererben. Der Runner betrachtet alle Klassen, die von BaseTest vererben, als TestFixtures. Folie 20 von 27 20

21 5. VOUnit Attribute Eine Beschreibung der Testmethoden im Konstruktur der Testklasse ersetzt die Attribute. Folie 21 von 27 Die Parameter an den Konstruktur von TestAttribute sind: symmethod nrepeat lignore aexpectedexceptions 21

22 5. VOUnit Assertions VO kennt keine statischen Methoden. Aber Funktionen. Folie 22 von 27 22

23 5. VOUnit Console Runner starten Die Test-DLLs werden als Parameter an die Kommandozeile übergeben. Folie 23 von 27 Status von VOUnit VOUnit ist eine Beta-Version. Es fehlen noch dringend: GUI Runner Mehr Assert-Funktionen Dennoch befindet sich VOUnit in unserem Entwicklungsteam bereits im Einsatz. Nun, da wir VOUnit zu Open Source machen, würden wir uns über Beiträge anderer Entwickler sehr freuen. 23

24 5. VOUnit Wann schreibe ich neue Tests? Fehlerbehebung Erst den Test schreiben, der den Fehler reproduziert, dann den Fix. Code wird überarbeitet (Refactoring) Was kann der alte Code eigentlich alles? Das ist der größte, frustrierendste und schwierigste Teil bei der Einführung. Neuer Code Es gelten dieselben Regeln wie bei komplett neuen Systemen. Unklare Schnittstellen Ich weiß nicht, wie eine Komponente, Klasse oder Methode richtig verwendet wird. Folie 24 von 27 When we get bug reports, we're trying to follow a methodology of writing a test first that fails. Then we fix the bug and make sure the test passes. Don Caton, , auf vo.vops.vulcandotnet 24

25 6. Mehr Testverfahren Weitere Bereiche und entsprechende Tools sind: GUI NUnitForms (Tests von System.Windows.FormsApplikationen) Mercury und andere kommerzielle Tools MVC-Ansatz (Trennung von zu testendem Code und Darstellung) Mock Objects Mock Objects bilden das Verhalten zu testender, externer Komponenten (z.b. serielle Schnittstellen) nach, damit automatische Tests laufen können. NMock oder DotNetMock Datenbank-Code SQLUnit oder NDBUnit Webseiten NUnitASP Folie 25 von 27 MVC-Ansatz Auch hier gilt der Verweis auf die Session von Meinhard Schnoor-Matriciani zu Design Patterns. Eine Reihe der hier genannten Tools sind Add-Ons zu NUnit. SQLUnit Das sicher recht leistungsfähige Tool ist in Java geschrieben und baut für Entwickler aus dem Bereich VO oder DotNet leider recht hohe Hürden hinsichtlich Installation und Definition der Tests auf. Ein gleichwertiges Pendant in der DotNet-Welt fehlt noch. 25

26 7. Integration von TDD in den Software-Entwicklungsprozess Ziel der Einführung von TDD muss die Integration in einen allgemeinen Qualitätsprozess (z.b. Extreme Programming) oder andere Agile Methoden sein. Dazu gehören: Versionskontrollsystem CVSNT, SubVersion, MS Team Services Build Tools für kontinuierliche Builds auf einem zentralen Integrationsrechner NAnt, MSBuild, CruiseControl.NET, FinalBuilder Qualitätssicherung Code Coverage mit NCover und NCoverExplore Kodierungsregeln überprüfen mit FXCop Design Patterns Folie 26 von 27 Build Tools NAnt: Der Klassiker der Open Source Gemeinde, sehr umfangreich, viele Plugins. MSBuild: Bestandteil des.net SDK, kann Visual Studio Solution Files (.SLN) laden. CruiseControl: FinalBuilder: 26

27 8. Fragen und Diskussion? Folie 27 von 27 27

28 Vielen Dank für Ihre Aufmerksamkeit! Gesellschaft für Softwareentwicklung und Unternehmensberatung mbh Martinstrasse Dortmund mifi@appfact.de Literaturverzeichnis Newkirk, Jim; Vorontsov, Alexei: Test-Driven Development in Microsoft.Net, Microsoft Press Wikipedia Homepage von NUnit: Beck, Kent: Extreme Programming. Die revolutionäre Methode für Softwareentwicklung in kleinen Teams; Addison Wesley Fowler, Martin: Refactoring: Improving the Design of Existing Code, Addison Wesley Clifton, Mark: Advanced Unit Test, Part V - Unit Test Patterns Ein schöner Überblick über Bücher, Software und Links hierzu findet sich in diesem Blog: 28