Windows Developer 9.16
Windows-Developer-9-16_Cover_595x842

Test first, build better

Erhältlich ab: August 2016
Umfang: 100 Seiten
Autoren / Autorinnen:
Gregor Biswanger, Olena Bochkor , Annette Heidi Bosbach, Peter Brack, Carsten Eilers, Andreas Glomm, Tam Hanna, Thomas Claudius Huber, Thomas Huth, Dr. Veikko Krypczyk, Sebastian Loose, Manuel Meyer, Marc Müller, Daniel Murrmann, Manuel Rauber, Roman Schacherl, Daniel Sklenitzka, Dr. Holger Schwichtenberg, Manfred Steyer, Oliver Sturm

95,00 134,80 

Abonnement Typ
Auswahl zurücksetzen

9,80 

Heft bestellen

magazin

Buchtipp
Heimautomation mit KNX, DALI, 1-Wire und Co.

Buchtipp
Multitasking mit AVR RISC-Controllern

Olis bunte Welt der IT
Alle Fehler getestet?
Oliver Sturm

testing

ViewModels testgetrieben entwickeln
Test-driven Development (TDD) in MVVM-Apps
Thomas Claudius Huber

Alles im grünen Bereich?
Teil 4: Unit- und Integrationstests mit Node.js
Manuel Rauber

web

REST-Dienste umsetzen
Teil 3: HATEOAS mit .NET in der Praxis
Daniel Murrmann

Sie haben Post!
Teil 3: Echte Push Notifications für progressive Web-Apps
Manfred Steyer

Der Desktop ist nicht genug
Ein erster Blick auf das Webentwicklungsframework Wisej
Andreas Glomm

ui

Kolumne: XAML Expertise
WPF und Windows-Apps
Gregor Biswanger

Apps mit Augen – das Vision- API
Bessere Interaktion – die Cognitive-Services-Reihe
Roman Schacherl und Daniel Sklenitzka

praxis

Parallel geht schnell
Teil 1: Grundlagen der parallelen Verarbeitung
Dr. Veikko Krypczyk und Olena Bochkor

Roaring V8 Preview
Eine Einführung in das neue Bing Maps AJAX Control
Sebastian Loose und Peter Brack

Funk mit Schwierigkeiten
Teil 1: Bluetooth unter Windows 10 Mobile im Einsatz
Annette Heidi Bosbach

Kalte Fusion
Microsoft Kinect zum 3-D-Scanner umrüsten
Tam Hanna

VSTS/TFS – ganz nach meinem Geschmack
Verschiedene Erweiterungs- und Anpassungsmöglichkeiten
Marc Müller

architektur/alm

Kolumne: .NETversum
Tipps und Tricks rund um .NET und Visual Studio
Dr. Holger Schwichtenberg

azure

Mobile-Apps von A bis Z
Einführung zum Thema Azure-Mobile-Apps mit Praxisbeispielen
Manuel Meyer

sicherheit

IoT und die Sicherheit
Sicherheit oder Geräte des Internet of Things?
Carsten Eilers

Sicher von Anfang an
Secure Boot – das Fundament des sicheren Windows-10-PCs
Thomas Huth

Liebe Leserin, lieber Leser,

sagen wir, wie es ist: Getestet wird ungern, selbst in Zeiten agiler Entwicklung, deren Herzstück das agile Testing ist. Doch gerade, wenn die Anwendungen immer komplexer und größer werden, egal ob Web-, Client-, Mobile- oder Serversoftware, führt kein Weg an kontinuierlichen Tests vorbei. Also schreibt man ein Stück Software und überprüft, ob es auch wirklich funktioniert – und fertig, richtig? Leider sieht es in der Realität dann doch ein wenig komplizierter aus. Denn allein die Ziele von Softwaretests sind vielseitig: So kann es etwa darum gehen, die Ursache für einen bestimmten Fehler aufzufinden, oder man will beweisen, dass ein neu kreiertes System einwandfrei funktioniert. Oder aber man steht vor der Entwicklung einer neuen Software und will über Tests bereits im Vorfeld abklären, dass die Erwartungshaltung an den Code erfüllt wird. So oder so gilt: Je nachdem, welche Zwecke man verfolgt, gibt es unterschiedliche Arten zu testen.

Unit-Tests – erst Testen, dann programmieren!

Gerade bei agilen Softwareprojekten gehört die Implementierung von so genannten Unit-Tests mittlerweile zum Handwerkszeug. Mit Unit-Tests lässt sich das Verhalten einer Komponente isoliert, d. h. ohne ihre Abhängigkeiten zu anderen Komponenten, überprüfen. Infolgedessen erhält man bei dieser Testart direkt jede Menge kleinerer Tests, die jeweils nur das Verhalten einer ganz bestimmten Komponente prüfen. Der ein oder andere von Ihnen dürfte dieses Verfahren bereits angewandt haben und aus der Erfahrung wissen: Je näher die Deadline rückt, desto mehr werden Unit-Tests vernachlässigt. Eine gute Möglichkeit, diesem Problem entgegenzuwirken, ist es, die Tests zuerst zu schreiben und dann zu programmieren. Der Vorteil dieses Test-First-Ansatzes ist, dass die Software automatisch testbar ist, was die Fehlerfindung erheblich erleichtern und beschleunigen kann.

Allerdings gibt es auch einige Vorbehalte gegenüber Test First, die nicht von der Hand zu weisen sind. Realistisch betrachtet wird man für Unit-Tests etwa genauso viel Quellcode wie für die eigentliche Funktionalität schreiben. Und natürlich kann die Implementierung etwas länger dauern, wenn man neben der Funktion auch noch Unit-Tests schreibt. Auf lange Sicht zahlt sich der höhere Implementierungsaufwand jedoch bestenfalls durch niedrigere Wartungskosten aus. Wer jahrelang auf die Programmierung der „alten Schule“ gesetzt hat, dürfte zudem feststellen, dass es gar nicht mal so leicht ist, gute Unit-Tests zu schreiben. Das erfordert ein Umdenken, das natürlich nicht von heute auf morgen erledigt ist. Das Schwierigste ist aber wie immer der Anfang, und dabei wollen wir Sie in dieser Ausgabe unterstützen: Eine kleine Einführung (u. a.) zum Thema Test-First-Entwicklung gibt Oliver Sturm gleich zum Einstieg in seiner neuen Kolumne (S. 9). Wie die testgetriebene Entwicklung in der Praxis abläuft, zeigt Thomas Claudius Huber in seinem Artikel „ViewModels testgetrieben entwickeln“ (S. 14). Wer es bisher nicht versucht hat: Rein in den Sattel und einfach mal ausprobieren! Und nicht vergessen: Nur testbarer Code, ist guter Code!

Scarlett Winter, Redakteurin
Twitter: @win_developer

PS: Kommentare, Anregungen zu den Themen und Ideen sind uns immer willkommen unter: redaktion@windowsdeveloper.de


Weitere Ausgaben

X
- Gib Deinen Standort ein -
- or -