Teamwork

Visual Studio ALM 2012 – nun zieht C++ gleich
Kommentare

In vielen Bereichen der Softwareindustrie vollzieht sich ein Trend hin zu kürzeren Releasezyklen mit dem Ziel, Software und Services agiler bereitstellen zu können und so den gestiegenen Anforderungen des Marktes gerecht zu werden. Theoretisch einfach, in der Praxis jedoch nicht immer und nur durch effizientes Teamwork zu erreichen.

Das zweiwöchentliche Update, für viele Webplattformen und Services schon zur Regel geworden, ist für andere Bereiche der Softwareindustrie noch in weiter Ferne. Dort betragen die Releasezyklen oftmals noch zwei Jahre oder länger. Sicherlich sind Releasezyklen abhängig vom jeweiligen Projekt, besonders wenn die Software nur einen Teil des Produktes ausmacht. Der allgemeine Trend geht jedoch deutlich zu kürzeren Zyklen. Für viele Teams stellt dies eine Herausforderung dar, weil mehrere Aspekte berücksichtigt werden müssen. Zum einen muss das Teamwork stimmen – die Kommunikation zwischen allen Beteiligten ist hier ein essenzieller Bestandteil – und zum anderen müssen die Werkzeuge, ob für Entwickler, Tester oder andere Projektbeteiligten transparent integriert sein, um einen effizienten Datenfluss und Automation zu gewährleisten.

Im Folgenden werden wir besonders darauf eingehen, wie Visual Studio ALM 2012 als Plattform Teams unterstützen kann, um diesen Anforderungen gerecht zu werden. Im Fokus stehen dabei auch speziell die Neuerungen für C++-Entwickler, weil es gerade in diesem Bereich signifikante Änderungen gibt, die C++ zu einem ebenbürtigen Partner von C# und VB.NET aufsteigen lassen.

„Succeed or Fail fast and Learn“

Kürzere Zyklen werden vor allem bei Start-ups meist intuitiv angewendet, was vor allem darin begründet ist, dass Start-ups durch die Anwendung des Prinzips von Build-Measure-Learn [1] erfolgreich Ideen in Produkte transferieren können. Die kontinuierliche Anwendung dieses Prinzips ermöglicht es Teams, eine Kultur zu etablieren, die Innovation fördert, indem erfolgreiche Konzepte schnell adaptiert und weniger erfolgreiche verworfen oder angepasst werden können, bevor sie im Produkt implementiert werden. Die Visual-Studio-Produktgruppe adaptiert dieses Prinzip für sich, was sich auch künftig in kürzeren Zyklen für Visual Studio widerspiegeln wird. Als Beispiel für „Measure-Learn“ kann aus der Entwicklung von Visual Studio 2012 die Tatsache dienen, dass basierend auf dem Feedback der Community das neue UX Design von der ersten Preview über die Beta bis zur finalen Version mehrere Anpassungen erfahren hat. Wer schon einige Jahre Software mit Visual Studio entwickelt, weiß, dass dies nicht immer so war.

„Flow“: der Schlüssel zum Erfolg

Betrachtet man zum Beispiel Scrum [2] als den wohl aktuell populärsten agilen Prozess, so erkennt man, dass auch er im Kern schnellere Zyklen ermöglicht. Abbildung 1 skizziert den groben Verlauf eines Scrum-Projekts.

Verlauf eines Scrum-Projekts

Im Produkt-Backlog werden die Anforderungen, in Scrum-Terminologie „Product Backlog Items“ (PBI) genannt, priorisiert und verwaltet. Die am höchsten priorisierten PBIs werden im Sprint als konkrete Aufgaben definiert und implementiert. Dabei liegt die gesamte Dauer eines Sprints in Scrum bei zwei bis vier Wochen; also recht kurz gehalten. In der Microsoft-Visual-Studio-Produktgruppe beträgt die Sprintdauer z. B. aktuell drei Wochen. Das Team trifft sich täglich zur Synchronisierung in einem kurzen „Daily Scrum“. Also quasi ein Zyklus im Zyklus. Das Ergebnis des Sprints ist ein so genanntes „Shippable Increment“, das durch Akzeptanztests verifiziert wurde und nun bereit ist für das Feedback durch den Product Owner, z. B. den Fachbereich, für den das Team ein Produkt entwickelt. Die Ergebnisse des Feedbacks, sowohl durch den Product Owner als auch das Team, fließen wieder in das Product Backlog ein. Betrachtet man diesen Prozess mit etwas Abstand, kommt man unweigerlich zum Schluss, dass die immer wiederkehrenden Abläufe sehr flüssig sein müssen, um den Verwaltungsaufwand auch bei kürzeren Zyklen in angemessenem Verhältnis zur produktiven Entwicklungszeit halten zu können.

Fragt man einen Sportler unmittelbar nach einer perfekten Leistung wie es gelaufen ist, bekommt man häufig die Antwort: „Lief super, ich war richtig gut im ‚Flow‘“. Ähnliches kann man auch bei Teams feststellen, die erfolgreich kurze Zyklen leben. In diesem Fall definiert sich „Flow“ als reibungsloses Teamwork mit funktionierender Kommunikation und dem positiven Effekt von Spaß und Enthusiasmus, Teil des Teams zu sein. An dieser Stelle sei es erlaubt anzumerken, dass die Autoren keine rosaroten Brillen tragen und sich durchaus bewusst sind, dass es sich hier um einen erstrebenswerten Idealzustand handelt.

Eines der Ziele von Visual Studio ALM 2012 ist es, Teams zu unterstützen, wiederkehrende Aufgaben zu automatisieren, Kommunikation im Team effizienter zu gestalten und Entwicklern besserte Werkzeuge für wiederkehrende Aufgaben zu geben. Ein Beispiel hierfür ist der neue Codereview Support, den wir noch genauer betrachten werden und der nicht nur für Teams mit kurzen Zyklen von Nutzen ist.

Prozesse unterstützen Teams, nicht umgekehrt

In der Softwareindustrie gibt es eine Vielzahl von Prozessen bzw. Vorgehensmodellen. Traditionell sind die eher „formalen“ Prozesse wie z. B. CMMI [3] oder V-Modell [4], die vor allem von Teams in regulierten Domänen, wie z. B. in der Medizintechnik angewendet werden. Zudem gibt es die agilen Prozesse, wie z. B. Scrum oder Kanban [5]. Genauso häufig findet man in der Praxis individuell angepasste Modelle, die als Basis meist einen in der Industrie bewährten Prozess nutzen. Prozessflexibilität ist ein wichtiger Aspekt von Visual Studio ALM 2012. Hintergrund hierfür ist unter anderem die kontinuierliche Evolution der Prozesse in der Industrie, die es Teams ermöglicht eigene Erkenntnisse, die vielleicht auch spezifisch für eine Domäne sind, umzusetzen. Der Team Foundation Server 2012 unterstützt hier zwei Szenarien. Basierend auf Prozessvorlagen stehen bewährte Prozesse wie CMMI, MSF Agile und Scrum zur Verfügung, die sofort direkt verwendet oder bei Bedarf angepasst werden können. Außerdem stellt der Team Foundation Service, aktuell als Preview [6] verfügbar, Prozesse wie z. B. Scrum bereit. Künftig werden diese anpassbar sein, aber nicht im gleichen Umfang wie im Team Foundation Server. Teams können nun wählen:

  • Volle Flexibilität mit dem Team Foundation Server 2012 für Teams jeder Größe und Konfiguration
  • „Always On“, kein Setup und in 10 Minuten produktiv mit einem bewährten Prozess und der Team Foundation Service Preview in der Cloud
  • Kostenfrei mit dem TFS 2012 Express mit Basisfunktionalität für kleinste Teams

Bei der Anwendung von Prozessen gelten für uns zwei Aspekte, die den Trend für kürzere Zyklen unterstützen: Prozesse unterstützen Teams und nicht umgekehrt. Sie sind dabei so leichtgewichtig wie möglich und so unterstützend wie nötig.

Teamwork ohne Teams?

Mit dem Team Foundation Server 2012 wurden Teams als Entität eingeführt. Teams können konfiguriert und Zugriffsrechte definiert werden. Der neue TFS 2012 Web Access bietet hierzu eine neue Oberfläche zur Administration. Kleine Organisationen werden mit einem Team auskommen und müssen sich hier keine weiteren Gedanken machen. Größere Organisationen, die ein Produkt mit mehreren Teams erstellen, können dies nun entsprechend konfigurieren. Hierbei ist vor allem das Backlog-Management von Interesse. Folgendes Szenario könnte hier Anwendung finden. Angenommen das Produkt wird von drei Teams implementiert. Statt eines einzelnen Backlog, wie in Abbildung 1 dargestellt, könnte dies ein Master-Backlog sein, von dem die PBIs in die Backlogs der Teams verschoben werden. Jedes Team arbeitet nun in seinem eigenen Backlog, wobei das Master-Backlog für das Produktmanagement der zentrale Einstiegspunkt ist.

Backlog und Task Management

Das Backlog und Task Management können direkt in Visual Studio durchgeführt werden, der TFS 2012 Web Access bietet hier aber eine optimierte Oberfläche. Web Access ist ein dynamisches Werkzeug und unterstützt Prozessflexibilität, sodass Inhalte dynamisch aus der Prozessvorlage geladen und entsprechend dargestellt werden. Auf diese Weise stellt ein Scrum-basiertes Teamprojekt andere Felder zur Verfügung, als ein CMMI-basiertes Teamprojekt. Das Backlog Management unterstützt Drag and Drop, um die Priorität von PBIs/Requirements zu verändern oder diese zu Sprints/Iterationen hinzuzufügen. Der Fokus ist hierbei immer wiederkehrende Aktivitäten so einfach wie möglich zu machen, um das Team in den „Flow“ zu bringen. Auch die Erstellung von Hierarchien im Backlog, also Parent-Child-Beziehungen können via Drag and Drop hergestellt werden. In TFS 2010 musste man hierzu noch die betreffenden Work Items einzeln bearbeiten.

Das Sprint/Iterations Backlog ermöglicht es, effizient konkrete Aufgaben für die PBIs/Requirements zu definieren. Die integrierte Kapazitätsplanung erleichtert die Kapazitätsplanung für den aktuellen Sprint und ist natürlich optional nutzbar. Ein Realtime Burndown Chart ist jederzeit im Zugriff und ermöglicht dem Team Transparenz für die verbleibenden Aufwände im aktuellen Sprint. Größere Teams, die in einem regulierten Umfeld arbeiten oder spezielle Anforderungen im Projektmanagement haben, könnten zusätzlich die Project Server Integration nutzen.

Und täglich grüßt das Murmeltier …. oder so ähnlich. Der in Abbildung 1 schon erwähnte Daily Scrum hat sich als effiziente Methode zur Synchronisierung des Teams in der Praxis durchgesetzt. Teams nutzen den Daily Scrum auch, um Aufgaben im Team zu verteilen. Als Werkzeug hat sich hier ein Taskboard durchgesetzt, das typischerweise Aufgaben durch handschriftliche Karten repräsentiert, die nach Status der Aufgabe und PBIs gruppiert eine großzügige Wand verschönern. Schön daran ist der physische Akt, an das Board zu gehen und eine Aufgabe vom Status „In Arbeit“ auf „Fertig“ zu verschieben. An diesem Punkt kann man Teams verstehen, die ein physisches Taskboard einem virtuellen vorziehen. Dennoch gibt es durchaus gute Gründe ein virtuelles Taskboard zu verwenden, z. B. falls ein Team über Standorte verteilt ist. Der TFS 2012 und Team Foundation Service bieten ein virtuelles Taskboard, das für Touch optimiert ist und somit das Gefühl eines physischen Boards vermittelt. Abbildung 2 zeigt das Board. Auf der linken Seite befinden sich die PBIs, die im Standard expandiert dargestellt werden und bei Bedarf verkleinert werden können. Expandiert befinden sich die dazugehörigen Aufgaben in der gleichen Zeile und je nach Status in der entsprechenden Spalte. Da in einem Daily Scrum typischerweise jedes Teammitglied der Reihe nach aktiv ist, gibt es hierzu einen Filter, der Aufgaben eines konkreten Benutzers hervorhebt, um das Bord übersichtlicher zu machen. Der Filter ist aber nicht nur für die Darstellung von Nutzen. Wenn z. B. bei aktiviertem Filter für ein Teammitglied eine Aufgabe in den Status „In Arbeit“ verschoben wird, ändert sich automatisch auch der Eigentümer der Aufgabe. Diese Funktion ist natürlich optional einsetzbar, erleichtert aber den typischen Ablauf eines Daily Scrum.

Web Access Taskboard

[ header = Visual Studio ALM 2012 – nun zieht C++ gleich – Teil 2 ]

Storyboards – Warum Bilder effizienter als Worte sein können

Geschriebene Dokumente werden in Praxis sehr häufig als einzige Spezifikation für Requirements verwendet. Diese Dokumente haben meist den Nachteil, dass für das Team ein hohes Maß an Interpretationsspielraum gegeben ist, der zu Missverständnissen zwischen Auftraggeber und Team führt. Daher werden diese Dokumente oft z. B. durch UML-Diagramme ergänzt, um die Anforderungen noch klarer zu definieren. Es gibt aber noch einen anderen Ansatz, der sich immer mehr durchsetzt, weil er gut funktioniert und sich besonders bei kurzen Zyklen bewährt hat: Storyboards.

Storyboards sind ein Instrument zur effizienten Kommunikation. Angenommen die Aufgabe besteht darin, das Interaktionskonzept einer neuen Navigationssoftware zu beschreiben, dann kann dies in einem sehr ausführlichen Dokument erfolgen oder in einem Storyboard, das visuell die verschiedenen Interaktionen darstellt. Dabei wird das UI nur visuell dargestellt, es existiert also keine reelle Implementierung. Wird nun dieses Storyboard vorgestellt, kann man sich sicher sein, dass, falls das Konzept nicht schlüssig ist, man sofort entsprechendes Feedback erhält. Bei einem Dokument würde es mehr Fragen geben, bevor man das gleiche Feedback erhält.

Als Werkzeug zum Erstellen von Storyboards gibt es nun ein neues Plug-in für PowerPoint. Warum aber PowerPoint zum Erstellen leichtgewichtiger Storyboards? Hier einige Aspekte, die für PowerPoint sprechen: Präsentationsfähigkeit, einfache Lernkurve zum Erstellen von Storyboards, fast jeder hat schon mal mit PowerPoint gearbeitet, Verbreitung, sodass die Storyboards ohne zusätzliche Installation konsumiert werden können.

Im Kern liefert das Plug-in zum Erstellen von Storyboards eine Shape-Bibliothek, die viele vorgefertigte UI-Shapes enthält, aber auch durch eigene ergänzt werden kann. Zur Visualisierung von Abläufen können die PowerPoint-eigenen Funktionen für Animationen verwendet werden. Für eine direkte Interaktion können Shapes mit Links versehen werden, um zwischen Slides zu springen. Also quasi „Klick auf Schaltfläche, dann gehe zu Slide 4, Klick auf Tabelle, dann gehe zu Slide 10. Zusätzlich bietet das Plug-in noch eine TFS-Integration, um Storyboards direkt mit Work Items verknüpfen zu können. Auf diese Weise können PBIs/Requirements einfach durch PowerPoint Storyboards ergänzt werden.

Warum kein Storyboard verwenden, um User Stories mit PowerPoint zu erklären? Es ist die einfache Erkenntnis, dass Bilder mehr sagen als Worte. Ein Video zum PowerPoint Storyboarding gibt es unter [6].

Feedback – Stakeholder sind Teil des Teams

Feedback ist eines der wichtigsten Elemente von Build-Measure-Learn. Wer kürzere Zyklen lebt, kann häufiger Feedback zum aktuellen Stand einholen und Korrekturen vornehmen. In Abbildung 1 ist dieses Feedback als „Product Feedback“ dargestellt. Als Beispiel soll hier ein Team herangezogen werden, das für einen Fachbereich eine Anwendung entwickelt. Der Fachbereich wird durch den Product Owner vertreten, der die Abläufe, die die Anwendung unterstützen soll, exakt kennt, aber kein Entwickler ist. Das Team möchte nun nach jedem Zyklus aktiv Feedback einholen und nutzt dazu den Microsoft Feedback Manager. Über den Web Access erstellt das Team eine Feedback-Anfrage, die dann an den Product Owner via E-Mail versendet wird. Der Product Owner kann den Feedback-Prozess aus der E-Mail heraus starten. Der kostenfreie Feedback Manager wird bei Bedarf installiert. Das Team konnte in der Feedback-Anfrage Instruktionen für den Zugriff auf die Anwendung definieren; einen Link zu einer Website, zu einem Setup oder zu einer virtuellen Maschine, die durch das Team provisioniert wurde. Der Product Owner absolviert im Grunde nur drei Schritte, die sehr einfach in dem Feedback Manager dargestellt werden:

  • Schritte für den Zugriff auf die Anwendung
  • Bewertung der Punkte, für die das Team um Feedback gebeten hat
  • Feedback senden

Hierbei kann der Product Owner wählen, welche Informationen er in das Feedback einfließen lassen möchte. Nur schriftliche Kommentare und Screenshots, ein Screenrecording, Voicerecording oder alles. Das Feedback wird dann direkt im TFS gespeichert, so kann sich das Team jederzeit die Kommentare des Product Owner anschauen. Bei kürzeren Zyklen erhöht sich naturgegeben die Frequenz dieser Feedback-Anfragen, sodass der Product Owner so einfach und effizient wie möglich Feedback breitstellen können muss, was essenziell für agile Prozesse ist.

Die Basis verbessern

Web Access bietet auch Zugriff auf Version Control und Team Builds, die wichtige Bestandteile des TFS 2012 sind und von den meisten Teams als erste ALM-Komponenten genutzt werden. Team Build ist der Schlüssel zur kontinuierlichen Automatisierung und somit ein Muss für alle Teams, die in kurzen Zyklen entwickeln wollen. Kontinuierliche Integration von Code, automatisierte Unit und Oberflächentests bis hin zu integrierten Deployment-Szenarien mit Lab Management unterstützen Teams im Flow zu bleiben. Im Kern profitiert Team Build von allen Neuerungen der Windows Workflow Foundation 4.5, die seit TFS 2010 als Workflow Engine verwendet wird. Version Control ist für Teams das Instrument, um parallel Code zu entwickeln, zusammenzuführen und die Änderungen im Griff zu haben. Jeder Entwickler nutzt diese Funktionalität täglich und ist daher ein wichtiger Bestandteil der zyklischen Abläufe. Mit TFS 2012 wurden einige Szenarien deutlich verbessert.

Hier die aus meiner Sicht wichtigsten Aspekte: Die neuen „Local Workspaces“ bringen ein deutlich verbessertes Offline- und Performance-Verhalten, da die Serverkommunikation nochmals optimiert und ein lokaler Mechanismus implementiert wurde, der im Offline-Modus auch die originale Version der Datei enthält, sodass der Vergleich von Änderungen im Offline-Modus nun möglich ist. Auch das direkte Bearbeiten der Dateien außerhalb von Visual Studio ist nun problemlos möglich. Eine Konfigurationsdatei kann einfach in Notepad editiert und via CMD oder Visual Studio eingecheckt werden. Dies ermöglicht auch Entwicklern, die ohne IDE oder mit einer IDE ohne integrierte Version Control arbeiten, ein einfaches Arbeiten mit dem TFS. Der fast wichtigste Aspekt sind die neuen Werkzeuge zum Vergleichen (Diff) und Zusammenführen (Merge) von Änderungen. Diese verfügen nun über Code Editor Support und sind direkt in die IDE integriert. Entwicklern stehen nun Funktionen wie z. B. IntelliSense in diesen Werkzeugen zur Verfügung, die das direkte Editieren erheblich erleichtern. Da aber vor allem das Mergen von Änderungen bei Entwicklern eine nicht sehr beliebte Aufgabe ist, da sich hier schnell Fehler einschleichen können, wurde nicht nur das Merge-Werkzeug verbessert, sondern auch die Merge-Logik des TFS, sodass nun deutlich mehr Szenarien automatisiert gelöst werden können. Entwickler greifen nun seltener zum manuellen Mergen und die Integration von Verzweigungen (Branches) wird somit erleichtert. Arbeitet z. B. jedes Team in einen separaten Branch, sollten die Teams regelmäßig in den Haupt-Branch integrieren. Denn je größer die Unterschiede in den Branches sind, meist durch lange Isolation, umso aufwändiger wird die Integration. Integrationen sollten so häufig wie möglich durchgeführt werden, um den Code-Flow zu optimieren.

Entwicklerkommunikation – Code Review

Code Reviews werden in vielen Entwicklerteams durchgeführt, weil sie mehrere Aspekte in einem einzelnen Arbeitsschritt abdecken. Durch regelmäßige Code Reviews können Fehler, insbesondere strukturelle Fehler und Verstöße gegen teaminterne Richtlinien, meist früher erkannt und behoben werden. Zusätzlich erhöhen sie den Wissensaustausch zwischen einzelnen Teammitgliedern. Mittelfristig erhöhen Code Reviews sowohl die Wartbarkeit des Codes als auch das Verständnis des Teams für den Code.

Die Durchführung von Code Reviews kann organisatorisch eine Herausforderung darstellen, müssen sich doch mehrere Personen zu einem konkreten Zeitpunkt gemeinsam vor den Code setzen. Und genau hier setzt Visual Studio 2012 mit seiner Code-Review-Unterstützung an, das System unterstützt bei der Organisation und Durchführung der Reviews.

Abbildung 3 stellt die neu in den Team Explorer integrierte Code-Review-Komponente dar. In einem ersten Schritt beantragt der Implementierer eine Review auf Basis seines sich aktuell in Bearbeitung befindenden Change Sets. Hierzu kann er auch mehrere Personen einladen, die der Review zunächst zustimmen müssen. Die zu einem Review gehörenden Informationen werden dabei als Shelveset (Code, Pending Changes) und als Work Item (Review) verwaltet. Ein Reviewer erhält automatisch die gleichen Informationen wie der Implementierer selbst. So werden ihm alle durch den Change modifizierten Dateien sowie die verknüpften Work Items angezeigt. Daneben haben alle Beteiligten auch die Möglichkeit, die Review mit Kommentaren zu versehen, und zwar auf Ebene der gesamten Review wie auch auf Ebene einzelner Codezeilen innerhalb einer Quellcodedatei. Jeder Reviewer kann die Review seinerseits als abgeschlossen erklären, der TFS verwaltet den Status für jeden Reviewer separat. Der Implementierer selbst kann anschließend die eingebrachten Anregungen einarbeiten und schließt die Review durch finalen Check in seiner Pending Changes ab. Alle Informationen hinsichtlich des Reviews werden automatisch an den entsprechenden Change Sets angehängt und dauerhaft verwaltet.

Der Vorteil dieser Unterstützung durch TFS liegt auf der Hand, sehr viele Code Reviews können nun offline durchgeführt werden, Besprechungstermine für Code Reviews müssen nur noch „bei berechtigten Zweifeln“ an der Korrektheit der Änderung organisiert werden. Und genau so soll es auch sein.

Code Review

[ header = Visual Studio ALM 2012 – nun zieht C++ gleich – Teil 3 ]

C++ Unit Testing

Entwickler selbst testen! Was sich für Manchen fast unglaublich anhören mag, ist dennoch Tatsache. Jeder Entwickler führt während der Entwicklung zahlreiche Tests durch, aber eben nicht so wie dies ein Tester machen würde. Ein Entwickler programmiert Tests und ruft in diesen Programmen seine eben realisierten Funktionen auf bzw. testet die erstellten Klassen und Komponenten. Sehr häufig schreibt er kleine Konsolen-Anwendungen, nach dem Muster „main() … und dann ran an den Speck“.

Diese Art des Testens ist zwar gut und wichtig. Das Problem dabei ist aber, dass die erstellten Testanwendungen oftmals keinen Eingang in die Version Control finden, sondern ein Schattendasein mit sporadischer Nutzung auf irgendeinem Entwicklerrechner führen. Das ist schade, da doch gerade ein programmierter Test sehr gut für eine Automatisierung und damit für die kostengünstigste Art der Testdurchführung geeignet ist. Eben hier setzen Unit Tests an. Ein Unit Test ist direkt mit der bisherigen Testanwendung vergleichbar; eigentlich wird lediglich main() durch eine andere Eintrittsfunktion ersetzt. Die so entstehenden Testkomponenten werden in der Version Control verwaltet, durch einen Build automatisch übersetzt und anschließend direkt durch den Build geladen und aufgerufen. Dieses Vorgehen trägt dann bereits bei einer ersten Überarbeitung der Komponente Früchte und der Test läuft danach automatisiert erneut ab. Die Erstellung des Testcodes geschieht in der Regel ohnehin und stellt daher keinen Mehraufwand dar. Gerade im agilen Umfeld, wo sich sehr häufig Anforderungen ändern und damit Anpassungen am Code oder gar der Architektur einer Anwendung vorgenommen werden, ist Unit Testing somit eigentlich unabdingbar.

Unit Testing gehört daher seit Jahren zu den Best Practices in der Java- und .NET-Entwicklung. C++-Programmierer sind hier etwas verhaltener. Zu Recht, sind doch die bislang verfügbaren Unit-Test-Frameworks für C++ verglichen mit den Möglichkeiten in der Managed Welt eher „rudimentär“. Hier legt Microsoft mit Visual Studio 2012 nach, es existiert nun ein Unit-Test-Framework auch für nativen C++-Code. Dieser besteht aus folgenden Teilen:

  • Makros: Diese erlauben es, Klassen und einzelne Funktionen als Unit-Test-Methoden zu kennzeichnen. Verwendet werden sie analog zu den in MFC und ATL verwendeten Massage- und Interface-Maps
  • Hilfsklassen und Methoden: Diese dienen im Wesentlichen dazu, dem Testframework das Ergebnis des Tests mitzuteilen.
  • Test-Runner: Dieser lädt die Testkomponente zur Ausführzeit, sucht nach den Tests, führt diese aus und protokolliert die Ergebnisse.
Listing 1
#include "stdafx.h" #include " CppUnitTest.h "  using namespace   Microsoft::VisualStudio::CppUnitTestFramework; using namespace std;  namespace MfcCalcLibTest {       TEST_CLASS(CalcTests)   {   public:      TEST_METHOD(TestPushCount)     {       vector v_in(CALC_SIZE);       for(int i=0; i

Listing 1 zeigt einen einfachen Unit Test. Über die Makros TEST_CLASS() und TEST_METHOD() wird der Code als Unit Test gekennzeichnet. Daneben existieren eine Reihe weiterer Makros, z. B. kann eine Testmethode durch das Makro TEST_IGNORE() auch temporär deaktiviert werden. Durch den Aufruf von Assert::AreEqual() wird das Ergebnis des Tests an den Test-Runner gemeldet, auch hier existieren eine ganze Reihe weiterer Methoden. Mehr dazu unter [7].

Auf diese Weise realisierte Unit Tests lassen sich nun direkt in Visual Studio oder im Kontext eines TFS Builds ausführen. In beiden Fällen kann im Unit Test Explorer sehr einfach das Fehlschlagen eines Tests nachvollzogen werden.

Beim Einsatz von Unit Tests ist natürlich auch von Interesse, welcher Code bei der Ausführung der Tests denn überhaupt durchlaufen wird. Hierfür wird nun auch für C++ eine Code-Coverage-Analyse angeboten. Abbildung 4 zeigt das Ergebnis einer solchen. Rot dargestellt sind die Codepassagen, die von keinem Test durchlaufen werden. Dies kann zwei Ursachen haben. Zum einen kann es sein, dass einfach ein Test fehlt; ob dieser nachgereicht werden sollte, kann von Fall zu Fall entschieden werden. Zum anderen kann es aber auch sein, dass der Code in der Anwendung tatsächlich nicht mehr genutzt wird. Durchaus auch interessant, denn wie erkennen Sie sonst solche Code-Zombies?

Code Coverage bei C++ Unit Testing

C++-Codeabhängigkeiten visualisieren

Kennen Sie die Situation, die Pflege eines alten Codebestands übernehmen zu müssen? Jeder, der diese Erfahrung schon einmal gemacht hat, weiß genau, dass es insbesondere der erste Bugfix in sich haben kann. Gesegnet ist, wer in dieser Situation mit einer Exception kämpfen muss, wer hingegen „nur“ eine falsche Berechnung korrigieren soll, kann dabei regelrecht verzweifeln. Oftmals haben Sie schlicht und ergreifend keine Ahnung, wo Sie überhaupt ansetzen müssen!

Hier hilft der Architecture Explorer von Visual Studio 2012. Dieser nimmt die Analyse des Quell- oder auch Binärcodes vor und bereitet die Informationen entsprechend grafisch auf. Dies erleichtert die Navigation innerhalb des Codes ungemein. Bei der Erstellung der Diagramme sind Sie eigentlich nicht sonderlich eingeschränkt. Alles, was in C++ bekannt ist, kann als Strukturkriterium herangezogen werden: Projekte, Namespaces, Klassen, Methoden, Dateien aber auch Abhängigkeiten zwischen denselben wie #include, Methodenaufruf und Verweise über Pointer und Referenzen.

In Abbildung 5 wird das Ergebnis einer Analyse über Namespaces, Klassen und Methoden dargestellt. Interessant dabei ist, dass auch die Methodenaufrufe im Diagramm enthalten sind. Sie können das Diagramm zur Navigation im Code verwenden. Klicken Sie auf eine Klasse, können Sie dies expandieren; klicken Sie auf eine Methode, so wird dargestellt, von wo aus diese aufgerufen wird bzw. welche anderen Methoden diese selbst aufruft. Und per Doppelklick gelangen Sie jederzeit an die entsprechende Codestelle.

C++-Architekturanalyse

Statische Codeanalyse für C++

Compiler-Fehler sind gute Fehler, da sie sehr früh im Entwicklungszyklus auftreten. Doch nicht alles führt zu einem Compiler-Fehler, obwohl es evtl. nicht richtig ist. Hierzu folgender Code:

if(a=5) { }

Hierüber ist jeder C++-Entwickler sicherlich schon einmal gestolpert, der kleine aber feine Unterschied zwischen Zuweisung und Vergleich in C++. Ein Compiler erzeugt hier üblicherweise keinen Fehler, ebenso das Dereferenzieren eines Zeigers, der als In-Parameter an eine Funktion übergegeben wird (Aufruf mit nullptr) oder der Aufruf von GetTickCount (Überlauf nach 49 Tagen). Diese Art von Fehlern können durch statische Codeanalyse zusätzlich zum herkömmlichen Compiler-Lauf minimiert werden. Visual Studio bietet hierfür eine Schnittstelle, die es erlaubt, auch eigene Analyselogik mit zu integrieren, sollten die im Lieferumfang befindlichen nicht ausreichen.

Fazit

Visual Studio 2012 ALM möchte Teams jeder Größe ideal dabei unterstützen, erfolgreich Projekte im Team zu realisieren. In diesem Release wurden vor allem immer wiederkehrende Aktivitäten besser unterstützt und die Integrationsdichte der einzelnen Komponenten erhöht. Teams können so einfacher den Trend zu kürzeren Zyklen umzusetzen und die damit verbundenen neuen Herausforderungen. Aber auch Teams, für die kürzere Zyklen nicht im Fokus stehen, profitieren von den beschrieben Funktionen, die ein besseres Teamwork und mehr individuelle Produktivität ermöglichen. C++-Entwickler erhalten besseren Support für tägliche Entwicklungsaufgaben und dieser Trend wird sich in den kommenden Releases weiter fortsetzen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -