Gefühlte 95% der Zeit war ich dabei als üblicher Teilnehmer unterwegs. Die einzigen Unterscheidungsmerkmale gegenüber der Allgemeinheit waren das rote Bändchen am Namensschild und der große Aufdruck „Speaker“ auf meinem Poloshirt. Die Insignien der Konferenzelite wenn man so will, welche schnellere Kontaktaufnahme und einige detailliertere Einblicke in die Organisation garantierten.

Die Sicht des Teilnehmers

Bevor ich auf letzteres eingehe sei aber zunächst erst einmal die Infrastruktur gelobt. Die Internetverbindung war schnell und funktionierte fast immer tadellos, nur manchmal bedurfte es einiger Anläufe um zum gewünschten Ziel zu kommen. Das Essen fand ich reichlich und weitestgehend gutschmeckend. Vor allem die Cateringidee bei der OpenNight mit Burgern und Hotdogs zum selber basteln hatte einen hohen Kreativitätsfaktor.

Nur als ich mir am ersten Tag irgendein Wirsing-Matsch-Patsch auf den Teller hievte hätte ich mir zum einen gern einen Schildchen mit kurzer Beschreibung gewünscht und vor allem eine etwas breitere Aufstellung der Tische mit dem Essen. Diese standen in den Stoßzeiten leider zu nahe bei einander, wodurch sich die Schlangen daran gegenseitig im Weg standen, was wiederum die Inbesitznahme der Leckereien beim Mittagessen zu einem kleinen Spießrutenlauf werden ließ an dessen Ende man sich mit irgendwas auf dem Teller zufrieden gab, Hauptsache raus hier.

Von den Vorträgen her bin ich nach wie vor zu großen Teilen begeistert aber leider auch etwas zwiegespallten. So war die Themenauswahl wirklich gut und gliederte sich in acht Kategorien zu je vier Tracks pro Tag, mit denen vom Requirements-Engieneering über die Architektur, automatisierten Tests und Deployment alles abgedeckt wurde, einschließlich Tipps und Tricks fürs Alltagsgeschäft.

Auf der anderen Seite muss ich jedoch auch Kritik üben. So hielt leider nicht jeder Vortrag das was die Ankündigung versprach. Dies lag zum einen an der fehlenden Schwierigkeitsstufe, die schon frühzeitig vor allzu seichten Themen gewarnt hätte, und zum anderen ein paar zu große Versprechungen seitens der Vortragenden.

Positiv hervor zu heben seien jedoch vor allem die Vorträge von Chris Rupp („Spezifizierst du noch oder implementierst du schon?“) die auf beeindruckende Weise die Komplexität der Kommunikation analysierte, Golo Rodens „JavaScript Best Practices“ der mit einfachsten Mitteln die schlimmsten Stolpersteine von JavaScript beschrieb und mir als zuvor Unwissenden dabei genug Futter gab um im Grunde die, leider erst darauf folgende, Einführung in JavaScript im Internet surfend zu verbringen. Weiterhin war die Keynote von Jeff Potter sehr unterhaltsam, auch wenn manche Pointe durch das Raster fiel, weil der Tag doch etwas sehr anstrengend war und somit wenig Platz zum Übersetzen im vollgestopfte Kurzzeitspeicher blieb.

Leider nicht mitnehmen konnte ich „Guck mal – Codereviews in der Praxis“ von Laurin Still und „Gestern Entwickler, heute ScrumMaster“ von Dr. Jürgen Hoffman und Heiko Stapf die mir nachträglich als sehr gut bescheinigt wurden, aber etwas ungünstig zu meiner eigenen Session lagen.

Die Sicht des Sprechers

Damit sind wir auch schon beim eigentlichen Auslöser für meine Teilnahme. In meinem Vortrag „MS Test – Der missverstandene Stiefbruder!?!“ widmete ich mich einer Gegenüberstellung von NUnit und MS Test sowie den unterschiedlichen Teststufen in der Qualitätssicherung und deren Automatisierungsgrad. Ob ich den Nerv meiner Zuhörer dabei traf kann ich leider nicht ganz einschätzen und würde mich hier über Feedback freuen.

Sehr ermutigend war jedoch die große Anzahl der Beteiligten die ich grob auf etwas zwischen 60 und 80 von insgesamt ca. 500 Personen schätzen würde. Dies ist für mich insofern erfreulich, da mein Thema nach eigener Einschätzung ein vergleichsweise umfangreiches Wissen voraussetzte und nicht wenig komplex war, ich anderer seits im Hauptteil aber nie das Gefühl bekam die Zuhörerschaft zu überfordern oder in den Weiten der Langeweile verloren zu haben. Dies zeigte sich zum Beispiel durch beständig in die Höhe gehende Hände auf Fragen meinerseits und interessiertes Nicken oder amüsiertes Kopfschütteln ihrerseits.

Hauptteil, ist hier ein wichtiger Punkt, denn leider habe ich mich im Vorfeld zeitlich ein wenig verschätzt. So habe ich in der Vorbereitung alles in allem für den Vergleich der Frameworks samt Zusammenfassung fast immer etwas über 50 Minuten benötigt. Plus einen Puffer für Fragen und Anekdoten also ein solider Zeitrahmen, der mich dazu bewog den Vergleich der Isolation Frameworks als Backup zu verwenden. Leider war ich jedoch schon nach 40 Minuten fertig und bekam bis auf eine Frage, bei der ich nicht helfen konnte, kein weiteres Futter. Die nun doch gezeigten Backupfolien wirkten daraufhin für mich irgendwie wie angeflanscht, was dem Verständnis sicher nicht dienlich war.

Was lernen wir daraus? Never change a running system! Vor allem nicht einen Tag vor der Konferenz! Dabei war genau diese Devise eigentlich der Grund warum ich bis auf zwei Folien nicht das Layout der Konferenz übernahm. Mit den, für meinen Geschmack, etwas zu großzügigen Rändern samt Begleitinfos hätte ich mir meiner Meinung nach andernfalls den Vortrag gekillt bzw. einen unverhältnismäßig hohen Umbauaufwand gehabt.

Obwohl ich also nicht ohne Fehler bin muss ich auch aus Sicht eines Sprechers Kritik an meinen Kollegen äußern. Ich habe viele erfrischende Ideen und kreative Vorträge gesehen. Es wird auch niemand gezwungen voll gestopfte Powerpoint Monstren mit Myriaden Folien zu produzieren, aber bitte Jungs die Leute zahlen teils nicht gerade wenig Geld für die Veranstaltung also solltet ihr den Inhalt einer Session auch nicht dem Funfactor unterordnen.

Zusammenfassung

Alles in allem bin ich aber sehr zufrieden. Das Hotel war klasse und super gelegen, die Menschen waren nett und gesprächig, der Wissensgewinn war beträchtlich und dank meines Sprecherdaseins war das alles auch fast gänzlich kostenlos. Danke an der Stelle noch mal an meinen Arbeitgeber Saxonia Systems die alle Kosten übernahmen die der Veranstalter nicht trug.

Nichts desto trotz, kann man sich durch den Zugriff auf private Member gelegentlich viel Arbeit sparen wenn es darum geht einen Test aufzusetzen und außerdem hilft es manchmal sogar beim Aufspüren von Bugs. Weiterhin ist es teils unumgänglich auch Dinge zu testen die als internal gekennzeichnet sind und demnach theoretisch nicht vom Testprojekt identifiziert werden könnten.

Internal

Für letzteres Problem gibt es gleich auch die schnellste Lösung, welche selbst über das Testen hinaus nützlich sein kann. So verfügt jedes Projekt einer Solution über eine Datei AssemblyInfo.cs. Darin enthalten sind Informationen wie die Versionsnummer, die eindeutige Guid der Assembly usw., zusammengefasst in einer Attributschreibweise.

In diese Datei kann das Attribut InternalsVissibleTo eingefügt werden welches den kompletten Namen der “befreundeten” Dll übergeben wird. Nach dem nächsten Kompilieren sind dann alle als internal gekennzeichneten Klassen, Methode etc. auch innerhalb des anderen Projekts abrufbar.

[assembly: InternalsVisibleTo("[Friendly.Name.Dll]");

Leider kann das Attribute immer nur für die gesamte Assembly deklariert werden. Eine selektive Freigabe für einzelne Klassen ist somit nicht möglich.

Private Member

Auf private Objekte zuzugreifen ist zumindest im Rahmen von Tests nicht viel schwieriger. So kann man natürlich selbst Reflection bemühen um Methoden aufzurufen o.ä. man kann dies aber auch einfach die Klasse PrivateObject erledigen lassen. Diese bekommt bei der Instanzierung den Typ oder gleich eine Referenz der zu kapselnden Klasse übergeben und bietet dann den vollen Zugriff auf alle Eigenschaften.

So verfügt sie über diverse Set- bzw. Get-Methoden mit denen Werte auf Eigenschaften und Felder gesetzten oder von ihnen gelesen werden. Darüber hinaus erlauben die zahlreichen Überladungen von Invoke das Ausführen einzelner Methoden oder Auslesen deren Rückgabewerte.

So wird im folgenden Beispiel ein Wrapper um den Testgegenstand (sut) gelegt, mit dem erst ein Pfad zu einer bestimmten Datei hinterlegt wird. Dann rufen wir eine interne Methode zum Laden der Dataen auf um sie danach auf Richtigkeit zu prüfen.

var accessor = new PrivateObject(sut);
accessor.SetField("_path", BindingFlags.SetField, "testdata.xml");
accessor.Invoke("Load_Internal");
IEnumerable<Data> loadedData = accessor.GetProperty("InternalData");

Assert.IsNotNull(loadedData);

Eine Einschränkung in Sachen Privatsphäre ergibt sich für PrivateObject in Sachen Vererbung. So ist es nicht möglich auf private Member einer Elternklasse zuzugreifen, weshalb das folgende Beispiel fehlschlägt. Der Wrapper der sich durch die Klasse ergibt, hat immer nur die gleichen Zugriffsrechte wie die Klasse die er kapselt. Würde im Beispiel der String also protected gekennzeichnet werden, ergäbe sich auch das erwünschte Ergebnis.

public class A
{
   private string a = "Hallo";
}

public class B : A
{ }

[TestClass]
public class Test
{
   [TestMethod]
   public void TestCase()
   {
      var sut = new B();
      var privateObject = new PrivateObject(sut);

      var result = privateObject.GetField("a").ToString();
      Assert.AreEqual("Hallo", result);
   }
}

Private statische Member

Einer der Hauptgründe “klassische” Singletons nicht zu verwenden, ist das Hindernis welches sie in Sachen Test darstellen. So führen sie zu Abhängigkeiten die nur schwer erkennbar und noch schwerer aufzubrechen sind.

Eine Klasse die hierbei hilft ist PrivateType. Dabei handelt es sich quasi um einen Bruder von PrivateObject, der den Zugriff auf alle privaten statischen Elemente einer Klasse zulässt und dabei dem gleichen Vorgehensmuster folgt wie wie PrivateObject. Zu sehen auch im folgenden Beispiel sieht:

var accessor = new PrivateObject(StaticSut);

accessor.SetStaticField("_path", BindingFlags.SetField, "testdata.xml");
accessor.InvokeStatic("Load_Internal");
IEnumerable<Data> loadedData = accessor.GetStaticProperty("InternalData");

Assert.IsNotNull(loadedData);

Accessor-Klassen des Visual Studio

Ein Nachteil von PrivateObject und PrivateType wird recht schnell bei der ersten Nutzung ersichtlich. Zwar kann man über die BindingFlags der Methoden einige Probleme ausschließen, dennoch neigt man bei den Angabe in Form von Strings sehr schnell zu Fehlern und das vor allem dann, wenn der Code refaktorisiert wird. Denn Magic-Strings sind bekanntlich nicht typsicher wodurch sie nur schlecht von diversen Tools analysiert werden können.

Aus diesem Grund bietet Visual Studio die Möglichkeit so genannte Accessor-Klassen zu generieren. Sie stellen automatisch alle privaten Member öffentlich zur Verfügung, aktualisieren sich selbst bei Änderungen am Code der eigentlichen Klasse und sind somit gänzlich typsicher, ABER laut Microsoft auch seit spätestens Visual Studio 2011 als deprecated zu betrachten.

Der Grund hierfür ist wohl, dass der dahinter liegende Generator mit dem steten Wandel in .Net nicht Schritt halten konnte/kann und seine Weiterentwicklung zumindest eingefrohren wurde. Das Feature existiert demnach hauptsächlich noch aus Kompatibilitätsgründen und könnte bei Portierungen auf höhere Framework- und VS-Versionen unter Umständen unangenehme Nebeneffekte aufweisen, weshalb sie besser nicht mehr verwendet werden sollten.

Sollen sie dennoch verwendet werden gibt es zwei Möglichkeiten einen Accessor zu erzeugen. So reicht es entweder die entsprechende Klasse im Editor zu öffnen und dort im Kontext-Menü “Create Private Accessor” auszuwählen oder sich einen Unit Test über den entsprechenden Wizard zu erzeugen. Letzteres generiert jedoch eine ganze Menge Code den man meist nicht braucht, weshalb ich dies eher ungern nutze.

Das Beispielszenario

Das Szenario ist im Grunde wie im vorangegangenen Artikel. Es geht darum die Logik für die Berechnung von Lottoergebnissen zu programmieren. Die dafür verwendeten Klassen unterscheiden sich jedoch, was hauptsächlich darin begründet ist, dass mein Programm mittlerweile ein wenig gewachsen ist und ich zu faul war extra ein Projekt nur für dieses Post hier aufzusetzen.

Grundsätzlich haben wir deshalb eine Klasse LottoTicket die die Ticketdaten des Spielers enthält. Dazu gehören alle Tipps die er auf dem Ticket gemacht hat, sowie eine eindeutige Referenznummer aus der sich die Superzahl ergibt. Weiterhin haben wir eine Klasse LottoDrawing mit den Daten der Ziehung.

Last but not least haben wir den PrizeCategoryCalculator den wir auch testen wollen. Er errechnet die Gewinnklassen aller Tipps eines Tickets, damit, wenn die Quoten feststehen, der Gesamtgewinn des Spielscheins errechnet werden kann.

Die Besonderheit ist nun, dass alle möglichen Berechnungen von Gewinnklassen überprüft werden sollen ohne einen allzu großen Aufwand im Test zu induzieren.

Der erste Wurf

Ein einzelner Test kann in etwa wie der folgende aussehen. Dabei fällt auf, dass die ersten 18 Zeilen  nur dem Aufsetzen der Testdaten (Arrange) dienen und, abgesehen von den tatsächlich verwendeten Werten, in allen folgenden Tests nahezu gleich bleiben. Hier wäre es also sehr hilfreich, wenn die Testmethode nur ein einziges Mal geschrieben und dann vom entsprechenden Framework mit Testdaten versorgt würde.

var sut = new PrizeCategoryCalculator();
var numbers = new List<int> { 1, 2, 3, 4, 5, 6 };
var givenTipp = new LottoTipp { RegularNumbers = numbers };

var givenDrawing = new LottoDrawing
{
   AdditionalNumber = 11,
   Date = DateTime.Now,
   RegularNumbers = numbers,
   SuperNumber = 9
};

var givenTicket = new LottoTicket
{
   RegistrationNumber = "02132309" + givenDrawing.SuperNumber,
   Tipps = new List<LottoTipp> { givenTipp }
};

var results = sut.Check(givenTicket, givenDrawing);
var result = results.FirstOrDefault();

Assert.IsNotNull(result);
Assert.AreEqual(PrizeCategory.I, result);

Testdaten bereitstellen

Um Testdaten mit MS Test bereit zu stellen, bedarf es zunächst einer Datenquelle. Diese kann entweder in Form einer Datenbank oder einer CSV bzw. XML Datei vorliegen. Bei CVS-Dateien ist es wichtig, dass alle Werte durch Kommas separiert sind was mit Excel nicht immer der Fall ist.

Um diese Datei einzubinden muss nun die Test View im Visual Studio über das Menü Tests -> Windows -> Test View geöffnet werden. Darin sind alle Tests zu sehen die aktuell verfügbar sind, desweiteren kann über F4 das Property Window des entsprechenden Tests geöffnet werden in dem zusätzliche Einstellungen verfügbar sind.

In genau diesem Eigenschaftsfenster ist danach der Wert Data Connection String auszuwählen, der leer sein müsste. Erst wenn er ausgewählt wurde erscheint auf der rechten Seite ein Button mit drei Punkten über diesen startet man einen Wizard zum Auswählen der tatsächlichen Daten.

Stimmt die Formatierung der Daten, sollte der letzte Dialog im Wizard in etwa wie folgt aussehen. Befinden sich alle Daten in nur einer Spalte, wurden bei CSV Dateien keine Kommas zum Trennen der Werte und bei XML eine ungünstige oder nicht wohl geformte Sturktur genutzt. Ein Klick auf Finish fügt anschließend die entsprechenden Attribute an den jeweiligen Test.

Bei diesen Attributen handelt es sich zum einen um DataSource mit welchem die Datenquelle beschrieben und dem, neben Informationen über den Typ der Quelle, auch deren Pfad und eine etwas sinnlos wirkende Angabe eines Tabellennamens übergeben wird. Darüber hinaus bedaruf es der Spezifizierung einer Datenzugriffsmethode, welche theoretisch entweder sequenziell oder zufällig geschehen kann. Praktisch funktioniert bei Dateien als Quelle, meines Wissens aber nur sequenziell…

[DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV",
            "|DataDirectory|\\WinCheck.csv",
            "WinCheck#csv",
            DataAccessMethod.Sequential)]
[DeploymentItem("MS_Test\\UnitTests\\WinCheck.csv")]

Das zweite Attribut, das automatisch angelegt wurde, ist das DeploymentItem. Über dieses werde ich sicher noch ein weiteres Post schreiben, denn es wir immer dann genutzt wenn automatisch Dateien oder andere Arten von Ressourcen deployt werden sollen. Darüber hinaus hat es einige Macken die man kennen sollte. Im aktuellen Fall reicht es aber zu wissen, dass die als Parameter angegebene Datei automatisch von Framework in das Ausgabeverzeichnis des Tests kopiert wird.

Testdaten verwenden

Nun werden die Daten vom Framework geliefert, doch wie greift man darauf zu? Hierzu braucht unsere Testklasse die Property TestContext vom gleichnamigen Typ. Diese enthält wiederum eine Reihe von Informationen die während eines Testdurchlaufs von Interesse sein könnte wie zum Beispiel das Verzeichnis in dem die Programmdaten liegen und eben auch die Daten aus unserer Quelle.

Auf jene wird dann in der eigentlichen Testmethode durch die Row Property des Contexts zugegriffen. Eine solche Row ist mit einer Zeile in den Testdaten gleich zu setzen, wobei die einzelnen Spaltenwerte über ihren Titel identifiziert werden.

var drawing = new LottoDrawing();
drawing.AdditionalNumber = Convert.ToInt32(this.TestContext.DataRow["Additional Number"]);
drawing.SuperNumber = Convert.ToInt32(this.TestContext.DataRow["Super Number"]);

Das zeilenweise Auslesen der Daten übernimmt MS Test für uns, welches die Test-Methode für jede Zeile erneut aufruft. Schlägt der Test für eine Zeile fehlt, werden alle anderen dennoch ausgeführt und gehen auch jeweils einzeln mit ihren Ergebnissen in die Auswertung ein. Zumindest wenn man den Testrunner von Visual Studio nutzt. Ist man, wie ich, überzeugter Nutzer des Resharpers erhält man von diesem nur das Gesamtergebnis aller Testfälle und darüber hinaus keine aufgeschlüsselte Fehlerbeschreibung falls etwas schief geht.

Die gesamte Testklasse sieht anschließend wie folgt aus, wobei jedes Ticket nur einen einzelnen Tipp enthält um die Komplexität an Testdaten möglichst gering zu halten.

public TestContext TestContext { get; set; }

[DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV",
            "|DataDirectory|\\WinCheck.csv",
            "WinCheck#csv",
            DataAccessMethod.Sequential)]
[DeploymentItem("MS_Test\\UnitTests\\WinCheck.csv")]
[TestMethod]
public void PrizeCategoryCalculator_shall_give_correct_prize_category_for_each_tipp()
{
   var ticketNumbers = new List<int>();
   var drawingNumbers = new List<int>();
   for (var i = 1; i < 7; i++)
   {
      var number = Convert.ToInt32(this.TestContext.DataRow["Ticket Number " + i]);
      ticketNumbers.Add(number);

      number = Convert.ToInt32(this.TestContext.DataRow["Drawing Number " + i]);
      drawingNumbers.Add(number);
   }

   var tipp = new LottoTipp { RegularNumbers = ticketNumbers };
   var ticket = new LottoTicket
   {
      Tipps = new List<LottoTipp> { tipp },
      RegistrationNumber = this.TestContext.DataRow["Registration Number"].ToString()
   };

   var drawing = new LottoDrawing();
   drawing.AdditionalNumber = Convert.ToInt32(this.TestContext.DataRow["Additional Number"]);
   drawing.SuperNumber = Convert.ToInt32(this.TestContext.DataRow["Super Number"]);
   drawing.RegularNumbers = drawingNumbers;

   var expectedResult = (PrizeCategory)Enum.Parse(
           typeof(PrizeCategory), this.TestContext.DataRow["Expected Result"].ToString());

   this.ActualTestImplementation(ticket, drawing, expectedResult);
}

public void ActualTestImplementation(LottoTicket givenTicket, LottoDrawing givenDrawing,
                                         PrizeCategory expectedResult)
{
   var sut = new PrizeCategoryCalculator();

   var results = sut.Check(givenTicket, givenDrawing);
   var result = results.FirstOrDefault();

   Assert.IsNotNull(result);
   Assert.AreEqual(expectedResult, result);
}

Fazit

Aus Entwicklersicht ist die Auslagerung der Daten in eine Datei sehr unangenehm. Während dies in reinen Testabteilungen sicher der Konsulidierung von Testdaten dient, ist es für Unit Tests reichlich kompliziert, unübersichtlich und entzieht sie jeder Art von automatischem Refaktoring. Darüber hinaus ist es außerdem fehleranfällig da die Daten nicht typischer vorliegen sondern erst konvertiert werden müssen und der Zugriff auf die Spalten in Form von Magic Strings geschieht.

Dort werde ich unter dem Titel: “MS Test -  der missverstandene Stiefbruder” im Grunde das auseinander nehmen, was ich die letzten zwei Jahre im Umgang mit der Visual Studio Test Integration und weitestgehend freien Alternativen erlebt habe. Genauer geht es mir dabei um die Lücke zwischen Unit Tests mit NUnit, Moq und Resharper, gegenüber den System- und Integrationstests mit Visual Studio, samt Pex und Moles.

Ich habe dabei nicht vor auf irgend welchen Designschwächen von was auch immer welchen Tools herum zu hacken. Viel mehr geht es mir darum die unterschiedlichen Sichtweisen gegenüber zu stellen die hinter den einzelnen Frameworks stehen, deren wichtigste Features zu erläutern und die Gründe zu nennen warum sie verwendet werden. Ob sie ihre Arbeit gut machen muss dann jeder selbst entscheiden.

Ich hoffe also auf eine rege Teilnahme und freue mich auf jeden den ich am 15. Mai willkommen heißen darf.

Ein immer wiederkehrendes Problem stellt für mich dabei die Nutzung des ItemsControl dar. Jenes zeigt die einzelnen Views in Form einer Liste an, was unter Umständen etwas langweilig und verwirrend wirken kann. Aus diesem Grund bietet es sich an, jene Views durch Überschriften oder Abgrenzungen voneinander zu trennen, aber wie kriegt man das hin? Kann man es evtl. auch ohne Prism verwenden? Und vor allem wie schafft man es mit möglichst wenig Aufwand?

Erst einmal völlig statisch…

Bevor wir uns Prism zu wenden, noch einmal kurz beschrieben was wir eigentlich tun wollen. Das grundlegende Ziel ist zunächst das Anzeigen mehrerer Controls in einer Liste. Dies kann wie folgt geschehen, wobei der Einfachheit halber Rechtecke statt UserControls verwendet wurden.

Der Vorteil eines ItemsControls gegenüber z.B. einer ListBox ist hierbei vor allem, dass keine Selektierung statt findet  sobald eines der enthalten UserControls den Fokus erhält, denn für den Anwender darf nicht ersichtlich sein, dass es sich tatsächlich um verschiedene Bestandteile handelt.

<ItemsControl>
   <Rectanlge Height="20" Fill="Red" />
   <Rectanlge Height="20" Fill="Blue" />
   <Rectanlge Height="20" Fill="Green" />
</ItemsControl>

Wie man im obigen Bild schon sieht, ist das etwas verwirrend da alle Controls dicht an dicht aufgereiht sind und somit die logische Gruppierung fehlt. Dies wird um so schlimmer je mehr Inhalt sie haben. Also wäre es doch besser sie untereinander abzugrenzen.

Dazu kann man entweder vor jedem Control einen entsprechend gestylten TextBlock einfügen oder wie folgt das HeaderedContentControl nutzen. Letzteres hat  den Vorteil, dass man die Einträge im Xaml besser unterscheiden und vor allem leichter stylen kann.

<ItemsControl>
   <HeaderedContentControl Header="Red" Style="{StaticResource ItemHeaderStyle}">
     <Rectanlge Height="20" Fill="Red" />
   </HeaderedContentControl>

   <HeaderedContentControl Header="Blue" Style="{StaticResource ItemHeaderStyle}">
     <Rectanlge Height="20" Fill="Blue" />
   </HeaderedContentControl>

   <HeaderedContentControl Header="Green" Style="{StaticResource ItemHeaderStyle}">
      <Rectanlge Height="20" Fill="Green" />
   </HeaderedContentControl>
</ItemsControl>

…dann etwas dynamisch…

Im dynamischen Fall werden die anzuzeigenden Controls nicht mehr fest angegeben, sondern aus einer Datenquelle bezogen. Hier ist die Abgrenzung über einen allgemeinen Style noch wichtiger als im statischen Fall, denn in diesem hat man wesentlich geringeren Einfluss darauf wie die geladenen Controls intern aufgebaut sind.

<ItemsControl ItemsSource="{Binding ControlSource}" />

Nun hat man zunächst aber ein weiteres Problem. Denn man muss irgend wie die Überschrift ermitteln die zuvor noch statisch angegeben werden konnten. Hier bietet sich die Nutzung eines Interfaces an, dass genau jene Property vorschreibt auf die der Header sich dann bindet.

public interface IHeaderedView
{
   string Header { get; }
}

Als nächstes müssen wir nun noch das Aussehen unseres Headers festlegen. Diesmal verwende ich kein HeaderedContentControl sondern überschreibe das ControlTemplate des ContentControls eines jeden Items. Sieht man sich den Code genauer an, merkt man sehr schnell, dass ich jetzt genau das tue, was ich im statischen Fall zu vermeiden versucht habe.

<Style x:Key="ItemHeaderStyle">
   <Setter Property="Control.Template">
     <Setter.Value>
         <ControlTemplate TargetType="{x:Type ContentControl}">
            <StackPanel>
               <TextBlock Text="{Binding Path=Header,
                    RelativeSource={RelativeSource TemplatedParent}}" />
               <ContentPresenter />
            </StackPanel>
         </ControlTemplate>
      </Setter.Value>
   </Setter>
</Style>

Der ContentPresenter spiegelt hierbei das tatsächlich hinzugefügte Element wieder, welches von einem StackPanel umgeben und dessen Header von einem TextBlock dargestellt wird. Der Text des TextBlocks ergibt sich nun aus der von IHeaderedView vorgeschriebenen Property. Damit diese Bindung funktioniert muss das Interface jedoch im CodeBehind der View umgesetzt werden.

<ItemsControl ItemsSource="{Binding ControlSource}"
              ItemContainerStyle="{StaticResource ItemHeaderStyle}"/>

Damit es aber nun wirklich wie gewünscht aussieht, muss der Style noch verwendet werden. Hierzu ist dieser dem ItemContainerStyle des ItemsControl zuzuweisen.

…zuletzt dann auch mit Prism.

Tja, das war eigentlich schon alles. Um Prism hier ins Spiel zu bringen muss man nun eigentlich nur das Binding auf die Liste der Controls entfernen und das ItemControl als Region bekannt machen. Wie so etwas aussehen kann, zeigt der folgende Code und das entsprechende Bild.

<ItemsControl Prism:RegionManager.RegionName="DiagramRegion"
              ItemContainerStyle="{StaticResource ItemHeaderStyle}"/>

Wen es interessiert: Als Ausgangspunkt für den Style im Bild wurde das Shiny Red Theme verwendet.

Weitere Infos

- WPF Content Model in der MSDN

- sehr gute Beschreibung zu Items Containern & Co.

Dank Professor Nestler hatte ich auf diese Weise wieder die Möglichkeit einen Spezialvorlesung an der HTW-Dresden zu halten. Nach dem ich mich beim letzten Mal im Juni vor allem der agilen Entwicklung und dem automatisierten Test gewidmet hatte, ging es dieses Mal um Pattern, Clean Code und Prism.

Für alle Anwesenden muss ich an der Stelle zugeben, dass die Vorlesung zunächst eigentlich zu MVVM und Prism geplant war und im Rahmen einer Lehrveranstalltung zum Thema WPF stattfinden sollte. Im Verlauf der letzten Wochen hat sich dies dann aber in eine etwas andere Richtung verschoben, so das Patterns allgemein und Clean Code mehr ins Zentrum gerückt sind.

Ziel war es daher auch nicht mehr so sehr, einen Einblick in die Praxis mit genanntem Framework und Patten zu geben, sondern eine Art Wegweiser zu errichten der Ideen geben sollte wie bestimmte Probleme umgangen werden können bzw. warum diese überhaupt erst auftauchen.

Für mich persönlich war es erneut eine Herausforderung die Informationen möglichst interessant und verständlich aufzubereiten. Immerhin sprechen wir hier über Themen deren Umfang und Komplexität auch so manchen erfahrenen Entwickler vor Probleme stellt.

Dass man dabei nicht alle Sachen die in diesem Rahmen gesagt und gezeigt wurden gänzlich in Form von Folien verfügbar machen kann, ist sicher einleuchtend. Ich hoffe aber das möglichst viele der Informationen noch immer in der Präsentation enthalten sind, zumal ich eine ganze Reihe von Bildern entfernen musste weil ich mich nicht sicher bin ob die von mir erworbenen Lizenzen eine Veröffentlichung im Internet einschließen.

Viel Spaß also mit den Folien und viel Erfolg bei zukünftigen Projekten.

Zwei Seiten helfen dabei besonders. Bei studiostyl.es kann man Styles für den Code-Editor des Visual Studios austauschen. Wem das nicht reicht, der kann mit dem Style-Generator basierend auf wenigen Eingaben einen entsprechenden Style generieren lassen. Importiert werden die entsprechenden Dateien dann ganz einfach über Tools -> Import and Export Settings…

Einige der Styles sind etwas gewöhnungsbedürftig, andere wirklich gut. Letztendlich kann es aber in Verbindung mit dem Resharper zu ein paar Problemen kommen, weshalb ich empfehlen würde die erweiterten Code Styles auszuschalten.

Außerdem funktionert bei den dunkleren Themes die Anzeige der aktuellen Zeile nicht so recht. Die Farben sind in aller Regel viel zu hell, weshalb man nicht erkennen kann was man gerade schreibt.

Sollte es Farben geben die man ändern möchte, kann man dies über Tools -> Options -> Environment -> Fonts and Colors tun.

Falls jemand außerdem daran interessiert ist das komplette Aussehen des Visual Studios zu verändern, kann er dies mit Hilfe des Visual Studio Color Theme Editors tun. Dieser “klingt” sich als eigener Eintrag in die Menüleiste ein und kann dann zu Laufzeit zwischen verschienden Farbeinstellungen wechseln bzw. über einen gesonderten Menüeintrag weitere Themes importieren.

Dank Dotnetpro und Co. sollte das Framework Prism mittlerweile recht bekannt sein. Es dient dazu WPF oder Silverlight Applikationen zur Laufzeit dynamisch „zusammen zu stöpseln“. Statt also während der Entwicklung fest zu legen welches UserControl wo hin geladen wird, legt man nur Regionen für die Steuerelemente fest und deren Inhalt wird dann dynamisch beim Start an genau diesen Stellen platziert. Dadurch können sie ohne weiteres ausgetauscht, wieder verwendet oder neu angeordnet werden.

Soll Zustand der Prism Anwendung mit einem TabControl in dem dynamisch die Views angeordnet werden.

Diese Regionen werden dabei  von einem so genannten RegionManager verwaltet bei dem sie und ihre zugehörigen Views registriert werden. Prism übernimmt dann die Auflösung aller Abhängigkeiten und die  Instanziierung der notwendigen Klassen.

Damit die Views sich aber bei den Regionen registrieren können, müssen jene identifiziert werden und das tut man in aller Regel über Strings. Und weil es natürlich sehr fehleranfällig ist, diese String immer und immer wieder einzugeben gilt es als Best-Practice eine statische Klasse zu schaffen in der all jene gesammelt werden. Somit werden im Xaml oder C# Code dann nur noch Variablen verwendet und die eigentlichen Strings sind völlig egal.

<TabControl p:RegionManager.RegionName="{x:Static c:Constants.MainRegion}"/>

Eigentlich, denn was passiert, wenn man die Strings ändert? Hier kommt es sehr stark darauf an wie man sie in der statischen Klasse hinterlegt hat, denn dafür gibt es zwei bzw. drei Wege. Der übliche und von StyleCop und R# geforderte ist dabei die Verwendung von konstanten Variablen:

public static class Constants
{
   public static const string ControlRegion = "controlRegion";
   public static const string MainRegion = "mainContentRegion";
   public static const string MenuRegion = "menuRegion";
}

Dies hat einen gewissen Vorteil, denn konstante Variablen werden zur Kompilier-Zeit aufgelöst und ihr tatsächlicher Wert wird dann vom Compiler an all jene Stellen geschrieben an denen sie referenziert werden; was auch der Grund ist warum nur die üblichen Wertetypen und Strings als const gekennzeichnet werden können. Auf diese Weise spart man zur Laufzeit das Fitzelchen Rechenzeit was bei einer üblichen statischen Variable verloren geht, weil erst deren Referenz aufgelöst und ihr Wert ausgelesen werden muss.

Fehlerhafter Ist-Zustand weil die Region aufgrund des falschen Namens nicht zugeordnet werden kann.

Der zweite und dritte Weg besteht dem gegenüber darin, eine statische nur lesbare Variable bzw. statische Property zu verwenden. Hier wird der Wert mit jedem Zugriff erneut ausgelesen, was nicht ganz so performant ist aber den Vorteil hat, dass die Werte nicht in die Aufrufer hinein kompiliert werden.

Ich gebe zu, so wirklich neu ist das für die Meisten sicher nicht. Es wird im Alltag aber schnell vergessen, wodurch dann Situationen entstehen bei denen man sich die Haare rauft.  Denn wenn man zum Beispiel im Zusammenhang mit Prism nicht darauf achtet und einfach mal die Strings der Konstanten ändert ohne alle abhängigen Dlls neu zu kompilieren, wundert man sich recht schnell warum die Views nicht mehr angezeigt werden und das obwohl man doch eigentlich „nichts“ geändert hat.

In dem Fall dann also einfach noch einmal alles komplett kompilieren, die strings nicht const mache oder halt niemals ändern…

Der Team Foundation Service ist eine Art Team Foundation Server  in der Cloud und basiert auf Azure. Laut Microsofts Aussagen richtet er sich vor allem an kleine bis mittlere Teams die den Aufwand scheuen einen eigenen TFS, mit dieser DBA hat sich Microsoft keine Freude gemacht, aufzusetzen.

Nachdem man dem Link in der Mail folgt, kommt man auf eine recht übersichtliche Webseite seinen Account einrichten und ein eigenes Teamproject anlegen. Team Projekte sind dabei ähnlich wie die Repositories aus SVN oder Git und bündeln logisch die Versionierung, Workitems und Co.

Zu jedem Projekt gehört auch ein spezielles Template welches bestimmt wie die Benennung der Workitems ist, welche Eingabefelder zur Verfügung stehen und welche anderen Features genutzt werden können. Ich habe mich an der Stelle für Scrum entschieden wodurch die nachfolgenden Beschreibungen auch nur auf dieses bezogen sind.

Nach etwa 5 Minuten ist das Projekt eingerichtet und es kann darauf zugegriffen werden. Danach kann man auch schon loslegen und die erste User Story anlegen. Denn bevor man etwas tut, sollte man auch wissen warum man es macht. Die dafür notwendigen Eingaben kann man komplett über den Browser tätigen.

Wer schon mit dem TFS und dem agilen Template gearbeitet hat wird die Eingabemaske weitestgehend kennen. Darin kann man typische Werte wie Aufwand und Business Value angeben, eine Person bestimmen die es umsetzen soll und evtl. weitere Arbeitspakete oder Tests damit verlinken. Letzteres erlaubt das gleiche Vorgehen wie beim großen Bruder wodurch ganze Abhängigkeitsbäume möglich sind.

Nachdem nun das Product-Backlog aufgebaut ist, fehlt noch die Iterationsplanung. Dazu muss zunächst festgelegt werden in welchem Zeitraum der erste Sprint läuft und anschließend welche Stories darin zu bearbeiten sind. Die Übersicht zur zeitlichen Planung der Sprints wirkt an der Stelle noch recht spartanisch.

Zur Planung der User Stories und Tasks bietet sich das Taskboard an. Dieses ist eine weitaus übersichtlichere Möglichkeit um die einzelnen Aufgaben einer Story zu verwalten. So sieht man in der Standardfilterung auf der linken Seite die jeweils geplante Story und rechts daneben die zu ihr gehörigen Aufgaben. Diese können über einen Klick auf das Plus direkt aus dem Board heraus erstellt und entsprechend verlinkt werden. Ihren Status kann man dann per Drag-and-Drop wechseln, in dem man sie von einer Spalte in die nächste zieht.

Leider habe ich keine Möglichkeit gefunden den Aufbau des Boards zu verändern. So wollte ich vor done noch einen Status Review einfügen. Dies ginge wahrscheinlich nur durch Anpassung des Templates, da sich der Aufbau des Boards implizit von den definierten Stati der Tasks ableitet.

Rechts in der Ecke des Boards gibt es einen kleinen Burndown-Chart, der auf Klick vergrößert dargestellt wird. In diesem wird jeweils die noch zu leistende Arbeit eingetragen und somit kann darauf geschlossen werden ob alle Features eines Sprints rechtzeitig fertig werden. Im Beispiel ist davon nicht viel zu sehen, weil ja auch noch nicht viel passiert ist.

“Leider”, wird anscheinend aktuell nur ein Burndown des Aufwands und nicht der Tasks angeboten. Da sich bei sowas gern verschätzt wird und die Verwaltung aufwändiger ist, würde ich ein Task-Burndown bevorzugen.

Nun haben wir die Arbeit, also fehlt noch das Vergnügen. Um den passenden Code  einchecken zu können, braucht man erstmal das SP1 und ein Hotfix für das Visual Studio. Danach kann man über den Team Explorer und mit Eingabe der eigenen Life-ID per Visual Studio auf den Service zugreifen, als wäre es ein “normaler” TFS. Dies bedeutet, dass man alle Workitems auch über das Visual Studio verwalten, Code aus- und einchecken aber nicht zum Beispiel die einfache Ansicht des Taskboards aufrufen kann.

Über den Team-Explorer kann man dann auch einfach seine Projekte hinzufügen, wobei sich das Tool recht schlau anstellt was eingecheckt wird und was nicht. Den Status der  einzelnen Dateien (neu, eingecheckt, ausgecheckt,…) kann man im Solution Explorer an einem kleinen Icon erkennen. Das Einchecken selbst passiert mit rechter Maustaste und über einen Dialog, in dem die Änderungen mit einem Kommentar versehen und mit den entsprechenden Aufgaben verlinkt werden können, alles genau so wie mit dem “echten” TFS.

Das nun entstandene Changeset, kann man sich im Portal genauer ansehen. Dabei ist es möglich sich über die damit verbundenen Änderungen genauer zu informieren, direkt durch den Code zu browsen und, das finde ich absolut Klasse, die Versionen einzelner Dateien direkt im Browser vergleichen.

Hat man Code, will man diesen auch bauen und so kämen wir jetzt eigentlich zum Build. Tatsächlich wird dieser aber (noch) nicht integriert angeboten. Vielmehr muss man einen eigenen Buildserver aufbauen und kann diesen dann mit dem Service verbinden. Welchen Aufwand das macht kann ich an der Stelle nicht sagen.

Letztendlich wirkt die Sache auf mich aber etwas eigenartig. Immerhin hat man jetzt seinen Code und alle Daten bei Microsoft liegen aber die tatsächlich rechenintensive Arbeit muss man immer noch selbst machen. Gerade in Zeiten von Continous Integration und Nightly Builds wäre eine Cloud-Lösung hier absolut wünschenswert.

Bleibt abschließend noch die Verwaltung und Benutzerführung zu erwähnen. Obwohl vieles durch das verwendete Template festgelegt wird, hat man noch eine ganze Menge Knöpfe an denen man drehen kann. Leider ist dabei nicht jeder Dialog so übersichtlich gestaltet wie die Benutzerverwaltung. Als Administrator kam ich mir gelegentlich doch recht verloren vor, wobei man sagen muss, dass ich auch zu keiner Zeit die Hilfe gelesen habe.

Alle anderen Projektteilnehmer werden mit einer einfachen Menüführung über 4 Hauptpunkte am oberen Rand verwöhnt und sollten sich schnell zu recht finden. Einzig bei der Suche nach den Backlogs war ich auch hier anfangs etwas verwirrt.

Fazit

Bis auf den letzten Punkt und bin ich vom Stand der Sache richtig gehend begeistert. OK, das Beta Preview läuft schon seit September aber die Stabilität, der technische Umfang und die Möglichkeiten die sich ergeben finde ich schon sehr gut. Lässt man einige Probleme außen vor, nutze ich den TFS an sich gern und könnte mich rein aus dem Bauch heraus für einen Umstieg begeistern. Ob dies aber wirklich geschieht hängt nicht zuletzt davon ab was es für Projekte damit entwickelt werden sollen (Thema Datenschutz und Compliance) und wie viel es letztendlich kostet.

Als der Termin dann jedoch endlich da war, gab es für mich das typische Problem aller Leistungsträger: Zu viel zu tun und zu wenig Zeit. Weshalb ich statt zwei nur einen Tag vor Ort sein konnte und leider auch die anschließende Party verpasst habe. Dennoch konnte ich an dem einen Tag weit mehr lernen und weit mehr interessante Menschen treffen als bei so mancher kommerziellen Veranstaltung.

Dies ging schon mit der Organisation und den einfachen Regeln des Tages los, die sinngemäß lauteten:

• Eine Session kann ein Vortrag sein, eine Diskussion oder Live Coding, es hängt komplett davon ab was gewünscht wird.
• Jede Session lebt von ihren Beteiligten und geht maximal eine Stunde.
• Vorbei ist vorbei, nicht vorbei ist nicht vorbei. Fragen also gleich stellen, sonst ist es vielleicht zu spät.
• Niemand muss in einer Session bleiben. Wenn es wo anders schöner ist, geht man halt da hin.

Darauf basierend, wurden dann entsprechende Themen gesammelt. Welche jeweils zunächst auf einen Zettel geschrieben und dann allen Beteiligten vorgestellt wurden. Jeder der sich dafür interessierte hob anschließend die Hand damit eingeschätzt werden konnte welche Raumgröße benötigt wird, bevor die Session dann grob in ein Zeitraster eingeplant wurde. Dieser Plan wurde dann, nachdem alle Sessions fest standen, von allen Beteiligten nach Belieben sortiert bevor es in die ersten Räume ging.

Letzteres sehe ich gewissermaßen als notwendiges Übel. Es ist verständlich, dass bei einer so agilen Veranstaltung keine Agenda existieren kann und demnach eine Raumplanung im Vorfeld unmöglich wird. Aber irgendwie hatte  ich das dumpfe Gefühl, dass die Räume über den Tag hin weg gern mal wieder umsortiert wurden. Zumindest ist es mir mehr als einmal passiert, dass ich in einem Raum saß in den ich zumindest anfangs gar nicht wollte. Naja, zumindest so lange bis ich gemerkt hatte, dass mich das „neue“ Thema auch interessierte.

Genau bei dem Punkt muss ich der Veranstaltung ein großes Lob aussprechen. Obwohl es viele Leute gab die, wie ich, wohl eher zum Konsumieren gekommen sind, gab es sehr viele sehr gute Sessions. Nach meinem Gefühl gab es genau die richtige Mischung aus typischen Wiederholungstätern, Technologiegurus und begeisterten Brötchen-Verdien-Programmierern. Auf diese Weise konnte ich gelegentlich eigene Erfahrungen zum besten geben und musste mich an anderer Stelle nicht ganz so tief verkriechen weil ich vom Thema noch nicht viel gehört hatte.

Mein Tagesablauf sah dann auch so aus (über die Reihenfolge bin ich mir nicht mehr sicher):

Windows Phone 7

Eigentlich wohl zum Live Coding gedacht artete es schnell in eine Marktanalyse aus, mit meinem späteren Entschluss auf Webapps umzusatteln bevor ich überhaupt mit WP7 anfange…

Mittagessen

Gesponserte Hühnerschenkel und dazu Diskussionen zum Praxiseinsatz von Specflow, UI-Testing und wo im V-Model sich Techniken wie BDD und TDD finden.

Für mich wichtigste Feststellung: V ist als Vorgehensmodell vielleicht nicht so hip wie Scrum und Co. aber es zeigt uns sehr einfach die Abstraktionsebenen der Software und gibt uns eine eindeutige Definition der Testarten wie man sie in der typischen online Literatur oft schmerzlich vermisst. (Man vergleiche nur mal die missverständlichen Betrachtungen in Blogs darüber was ein Unit-, Integrations-, System- und Akzeptanztest ist…)

WTF is a Type Provider?

Steffen Forkman zeigte wie man mit F# 3.0 Typen während der Programmierzeit(!!!) dynamisch und ohne Kompilierung aus einer Beschreibung eines Webservices oder anderen Quellen erstellen kann, wodurch typsicheres Programmieren ohne großen Aufwand möglich wird.

Neben dem Microsoft Bashing eindeutig mein Highlight des Tages.

[Session Hopping]

Eine Stunde lang von einer Session zur anderen hüpfen und irgendwie überall mal rein schnuppern, auf dem Gang mit Leuten reden und ungestört das Buffet plündern. Wunderbar!

Event Based Components und Flow Design

Man baut sich für jede grundlegende Funktionalität eine Klasse mit nur einer Methode. In „Platinen“ oder „Controller“-Klassen stöpselt man diese dann zusammen und erreicht damit eine bessere Austausch- und Testbarkeit.

Auch wenn Björn Rochel und Stefan Lieser mir in der Session das Brett vor dem Kopf entfernt haben, kann ich ehrlich gesagt dennoch nicht ganz so viel Begeisterung dafür entwickeln. Was wohl auch an meinen schrecklichen Erfahrungen mit graphischen Editoren für flussgesteurte Systeme liegt.

Feature Toggeling

Mit Feature Toggels schaltet man vor, beim oder nach dem Release Features aus bzw. ein. Dabei handelt es sich in aller Regel um modifizierte If-Statements die jeweils den Abarbeitungspfad ändern.

Hier habe ich still in meiner Ecke gesessen weil ich einfach nicht mitreden konnte. Ich bin Desktopentwickler und unsere einmonatigen Releasezyklen haben wir uns vor allem deshalb auferlegt um schnell fest zu stellen wenn es irgendwo hakt. Für mich war die Diskussion aus einem anderen Grund interessant: Sie erlaubte einen Einblick in die Arbeitsweise mit sehr kurzen Releasezyklen und den damit verbundenen Problemen aber auch Vorteilen.

Bash Microsoft

Wie beschreibt man so etwas für Leute die nicht da waren? Sagen wir mal so: Die beiden Microsoft Evangelisten haben mit Sternburg Export ausgerechnet das Bier ausgegeben was ich in dem Zusammenhang eher mit SEHR fußballbegeisterten Mitbürgern in Verbindung bringen würde, die sich gerade beim Heimspiel gegen ihren verhassten Erzrivalen befinden. Ob sie das beabsichtigen weiß ich nicht, ich weiß aber auch nicht was sie mit der gesamten Diskussion bezweckten.

Natürlich ist es verständlich, dass sie uns Entwicklern die Firma und ihre Produkte näher bringen wollen. Aber aus meiner Sicht kann es lediglich der Unterhaltung der Anwesenden gedient haben als des ernsthaften Informationsaustausches. Und so wurden die beiden von der geballten Kompetenz der .Net-Community auseinander genommen ohne, dass es am Ende ernsthaft neue Erkenntnisse gegeben hätte.

Dank des Biers und Popcorns war die Situation aber dermaßen schräg, dass ich mich die ganze Zeit in einer Sitcom wähnte und unterbewusst auf die eingespielten Lacher wartete. Wobei diese gar nicht nötig waren weil sich der Humorlevel konstant auf hohem Niveau befand.

Fazit

Zusammenfassend lässt sich also noch einmal sagen: Die Organisation war klasse, der Spaßfaktor riesig und nächstes Jahr werde ich versuchen wirklich 2 Tage da zu sein. Vielleicht gewinne ich dann auch mal was…