© S&S Media, © iStockphoto.com/danleap
Test-driven Development (TDD) in MVVM-Apps

ViewModels testgetrieben entwickeln


Einer der zentralen Vorteile des Model-View-ViewModel-Patterns (MVVM) ist es, dass sich ViewModels automatisiert testen lassen. Das ViewModel ist unabhängig vom UI und enthält nur die UI-Logik; eine Tatsache, die es zu einem idealen Kandidaten für Unit-Tests macht. Doch um ein testbares ViewModel zu erhalten, muss ein Entwickler ein paar Punkte beachten, insbesondere beim Laden von Daten oder beim Anzeigen von Dialogen. Worauf es ankommt und wie ViewModels testgetrieben entwickelt werden, zeigt dieser Artikel. Dabei werden das Unit-Testing-Framework xUnit, die Mocking Library Moq und das Dependency-Injection-Framework Autofac eingesetzt.

„Ich habe genug zu tun, da hab‘ ich doch nicht noch Zeit, um Unit-Tests zu schreiben“. Diese Aussage hört man nur allzu oft von Entwicklern, insbesondere von jenen, die noch nie in einem testgetriebenen Projekt mitgearbeitet haben. Von Michael Feathers, Autor des erfolgreichen Buchs „Working with Legacy Code“, stammt folgendes Zitat: „Code ohne Tests ist schlechter Code“. Der Grund ist folgender: Wenn es Tests gibt, kann ein Entwickler das Verhalten des Codes sehr schnell und verifizierbar ändern, da er nach dem Ändern des Codes die Unit-Tests laufen lässt, um zu sehen, ob er nicht aus Versehen bestehende Logik zerstört hat. Ohne Tests kann der Entwickler nach dem Ändern des Codes niemals wissen, ob der Code jetzt besser oder schlechter ist.

In diesem Artikel wird nur „guter Code“ geschrieben. Nach einem Blick auf Unit-Tests, Test-driven Development [1] und das xUnit-Framework zeigt der Artikel, wie testbare ViewModels geschrieben werden und wie sie sich testen lassen.

Unit-Tests

Ein Unit-Test ist ein automatisierter Test, der bekanntlich ein Stück produktiven Code testet. Ein Unit-Test erfüllt dabei verschiedene Eigenschaften, die unter dem Akronym F.I.R.S.T zusammengefasst sind [2]. Unit-Tests sind schnell (Fast), unabhängig voneinander (Isolates), wiederholbar in einer beliebigen Umgebung (Repeatable), selbstvalidierend (Self-validating) und werden zeitlich mit oder sogar vor dem produktiven Code geschrieben (Timely).

Damit diese Eigenschaften eines Unit-Tests erfüllt sind, muss der produktive Code ein entsprechendes Design erfüllen. Beispielsweise muss es möglich sein, den Unit-Test in einer beliebigen Umgebung zu wiederholen (Repeatable): im Zug, zuhause, im Büro oder sogar auf dem Mond ohne Internet. Das bedeutet, dass beispielsweise ein Datenbankzugriff nicht im produktiven Code enthalten sein darf; er muss mit ei...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang