TextTrimming zeigt bei einem Überlauf eines Textes automatisch 3 Punkte an – im Gegensatz zum Beispiel ohne TextTrimming, wo das ganze einfach abgeschnitten wird.

Die Umsetzung könnte einfacher nicht sein:

<TextBlock Text="Ich bin ein langer Text" TextTrimming="WordEllipsis" Width="116" />

Mehr Verfeinerungsmöglichkeiten gibt es zwar – wie etwa bei WPF – nicht, aber immerhin.

Da meckert also der Compiler “Cannot resolve ‘EntityState’”. EntityState ist ein Property, welches in der Klasse EntityObject definiert ist – welche in Nicht-Poco-Szenarien die Basisklasse aller Entities ist. Da die POCO’s natürlich nicht von dieser Klasse ableiten (und dies auch nicht tun sollen), ist hier eine Alternative gefragt.

Die ObjectContext-Instanz bietet Zugriff auf den ObjectStateManager. Mit dessen Methode “TryGetObjectStateEntry” kann man den EntityState jeder Entität herausfinden. Eine entsprechende Hilfsmethode könnte so aussehen:

private EntityState GetEntityState(object entity)
{
    ObjectStateEntry stateEntry;
    if (ObjectContext.ObjectStateManager.TryGetObjectStateEntry(entity, out stateEntry))
    {
        return stateEntry.State;
    }
    return EntityState.Detached;
}

Noch einfacher wirds, wenn die Entitäten eine gemeinsame Basis teilen (hier BaseEntity). Mit etwas ExtensionMethod-Magic lassen sich die notwendigen Anpassungen an der generierten Service-Klasse dann auch mit “Find and Replace” lösen:

private EntityState GetEntitySate(this EntityBase entity, ObjectStateManager stateManager)
{
    ObjectStateEntry stateEntry;
    if (stateManager.TryGetObjectStateEntry(entity, out stateEntry))
    {
        return stateEntry.State;
    }
    return EntityState.Detached;
}

Eigentlich etwas armselig, dass sowas überhaupt nötig ist – aber zumindest eine einigermassen komfortable Lösung.

Um einen Data Generation Plan zu machen, muss man ein Datenbank-Projekt erstellen.

Dann importiert man die Schema-Informationen.

Danach kann man dem Projekt einen neuen Data Generation Plan anfügen.

In dem Generation Plan können dann pro Feld einige Einstellungen zu den Generierungsdaten gemacht werden – und vor allem kann auch die Anzahl der zu generierenden Datensätze definiert werden.

Dann nur noch den Plan starten – und schon ist die Tabelle voll von Daten

So mächtig wie der Data Generator von Red Gate ist das zwar bei weitem nicht, aber so für eine einfache Testdaten-Generierung reicht das allemal.

Die TechDays fanden dieses Jahr im Congress Center in Basel statt. Die Location war soweit in Ordnung, ausser das in div. Sessions die Internetverbindung unbrauchbar instabil war – wer auch immer dafuer grade stehen muss, kriegt hoffentlich einen Rüffel. Wenigstens auf die Swisscom Hotspots war verlass, so konnte auf diese ausgewichen werden.

Aber das wichtigste sind wohl die Sessions, und diese enttäuschten (mit wenigen Ausnahmen) durchs Band.

Schon die KeyNote liess nichts gutes erahnen: nachdem man die zwei, milde gesagt, unkomischen Komiker ertragen hatte, gabs einen Vortrag über das eigentlich sehr verheissungsvolle Thema Film-Effekte. Leider war das ganze viel zu wenig konkret und technisch, so dass es mehr oder weniger darauf hinauslief, dass man Szenen aus Hellboy II (ohne Ton) geniessen konnte. Da wäre mehr drin gelegen.

Die eigentlichen Sessions fingen dann sehr gut an. Ronnie Saurenmann gab bei seiner Silverlight 4 Introduction alles! Das war komischer als die beiden angestellten Komiker und informativ zugleich. Bis auf die Advanced Silverlight-Session (wieder von Ronnie Saurenmann) konnte man den ersten Tag aber getrost vergessen. Tiefpunkt war der zweiteilige Vortrag “Sharepoint fuer Entwickler” von Olaf Feldkamp. Da war einfach viel zu wenig Fleisch am Knochen und das ganze war trotz des Titels eher auf ein Management-Publikum ausgerichtet.

Am zweiten Tag kann ich nur die Session von Michael Hofer zu den Sandboxed Solutions positiv herausheben. Der Inhalt war dem Publikum entsprechend technisch und hatte auch etwas Tiefe. Vorgetragen war das ganze locker und angenehm. Schade nur das Michael den Lumpensammler-Slot ganz am Schluss erhalten hat.

Ansonsten hätte ich auch den zweiten Tag besser an der Sonne verbracht.

Als Tüpfelchen auf dem i stellte sich dann das “Abschlussgeschenk” von Microsoft heraus. Beim rauslaufen erhielt jeder Teilnehmer eine gefuellte Strandtasche – gefuellt mit Werbung – komplett für die Tonne. Das alles in Kombination ist fast schon eine Frechheit für eine Veranstaltung die fast CHF 520 kostet. Da habe ich an kostenlosen (Partner-) Events von Microsoft schon viel besseres erlebt.

Ach ja – damit sich der Kreis wieder schliesst. Nein auch das Essen holte das ganze nicht raus. Es war zwar einigermassen ok, aber mehr auch nicht.

Ich hoffe MS geht hier für naechstes Jahr nochmals  ueber die Bücher – sonst waren das meine letzten TechDays. Gefordert sind mehr Tiefe, mehr Technik, weniger Marketing – und gutes Essen Und bitte lasst das mit den Drittliga-Komikern, das braucht niemand.

Die entsprechende Option kann in den ReSharper-Optionen aktiviert werden:

Nachdem in meiner Twitter-Timeline der #git-Hashtag immer öfters auftauchte, schaute ich mir das doch  mal etwas genauer an. Ein paar Tage später, laufen sind nun alle meine SVN-Repositories nach git migriert…

Was ist git?

git gehört zu den Distributed Version Control Systemen. Verteilt heisst hier, dass es nicht ein zentrales Repository gibt, sondern eben verschiedene, verteilte. Holt man sich bei Subversion eine lokale Arbeitskopie eines Repositories, hält man sich bei git das komplette Repository lokal. Ein lokales Repository bietet diverse Vorteile:

• Offline Commits: Da ich lokal nicht nur eine Arbeitskopie habe, sondern aber ein komplettes Repository samt History, kann ich auch lokal (bzw. offline) committen. Auch für Diffs etc. ist kein Online-Zugriff notwendig.
• lokale Branches: Auch Branches können dementsprechend lokal erstellt werden, ohne dass die Co-Devs jemals etwas davon erfahren müssen
• Geschwindigkeit: Files adden, committen – es flutscht gewaltig
• Speicherplatz: Durch die Art wie git intern arbeitet, braucht es massiv weniger Speicherplatz wie Subversion (massiv kann durchaus Faktor 2-3 heissen).

Jeder Entwickler hält sich also lokal ein Repository. Natürlich muss es dann trotzdem irgendwo ein “Master”-Repository geben, wohin dann die Änderungen dann mal gepusht werden. Dies alles bedarf natürlich möglichst effizienten und einfachen Branching und Merging-Mechanismen – da hab ich noch nicht allzuviel probiert, aber was ich bis jetzt gesehen habe reicht, um Subversion in Rente zu schicken!

Bald folgt mehr

Der Resharper bringt hier schon einige von Haus aus mit:

Da gibt es solche darunter, die einem einfach etwas Tipparbeit sparen (aus “thr” resultiert “throw new “) und andere, die etwas aufwändigere Konstruktur kreieren, so entsteht aus “itdic” eine Iteration über ein Dictionary:

Dabei sind die grün bzw. blau hinterlegten Bezeichnungen Platzhalter, welche mit TAB durchsprungen werden können – so hat man das eingefügt Snippet innert kürze für die jeweilige Situation angepasst. Resharper probiert bei der Wahl der Platzhalter jeweils auch herauszufinden, was man tun möchte. So leitet er aus meiner vorgängigen Initialisierung des dic-Dictionaries automatisch ab, dass ich wahrscheinlich darüber iterieren möchte, und dass dieses Dictionary einen Key vom Typ Integer und den Wert als String enthält.

Wer sieht den Fehler? Genau, die Iterationsvariable ist vom Typ DictionaryEntry statt KeyValuePair und die Casts im Body sind überflüssig. Das heisst, dieses Live Template ist für die Verwendung mit “klassischen” Dictionaries gedacht, nicht aber für generische.

Was nicht ist, kann ja noch werden

Und hier wirds erst richtig spassig. Live-Templates können auch ganz einfach selbst erstellt werden. Hierfür gibt es einen einfachen Editor, wo man sich die Live-Templates erstellen kann. Unser angepasstes Skript von oben sieht nun folgendermassen aus:

Man definiert also das Template mit Platzhalter. Für diese wiederum kann man dann Makros definieren, welche dem Live Template eine gewisse Inteligenz mitgeben. So wird hier als Beispiel für den DICT-Platzhalter definiert, dass eine Variable vom Typ System.Collections.Generic.Dictionary vorgeschlagen werden soll. Dies veranlasst Resharper bei der Verwendung des Templates dann dazu, im Code nach einer entsprechenden Variable zu suchen.

Wenden wir nun das Template auf unseren Code von oben an:

Et voilà – nun passts perfekt. Die Typen werden korrekt erkannt und die Iterationsvariable hat jetzt auch den korrekten Datentyp. Nettes Gimmick dazu: Im eingeblendeten DropDown macht uns Resharper gleich noch Namensvorschläge die an dieser Stelle evtl. Sinn machen könnten.

Mit ALT+< erhalt liefert mir R# eine Liste aller Members der gerade offenen Klasse:

Wie man sieht lässt sich die Liste auch durchsuchen

Hier ein (etwas sinnfreies) Beispiel – auch hier das ganze wieder mit xUnit und den xUnitBddExtensions:

   1: [Concern(typeof (Television))]

   2: public class when_Television_gets_turnOff_command_if_it_is_turned_off : InstanceContextSpecification

   3: {

   4:     private Action theTurnOffAction;

   5:

   6:     protected override Television CreateSut()

   7:     {

   8:         return new Television();

   9:     }

  10:

  11:     protected override void Because()

  12:     {

  13:         theTurnOffAction = The.Action(() => Sut.TurnOff());

  14:     }

  15:

  16:     [Observation]

  17:     public void Should_throw_an_NotYetTurnedOnException()

  18:     {

  19:         theTurnOffAction.ShouldThrowAn();

  20:     }

  21: }

In Zeile 13

theTurnOffAction = The.Action(() => Sut.TurnOff());

wird ein Action-Delegate gespeichert, welches dann auf Zeile 19 im Hintergrund aufgerufen wird.

theTurnOffAction.ShouldThrowAn();

Ein weiteres Beispiel für schön lesbare und somit aussagekräftige Tests.

Nachfolgender Artikel (und folgende) sollten nicht als Experten-Essay verstanden werden – vielmehr soll es Einsteigern helfen, die die gleichen Fehlüberlegungen machen und sich in die gleichen Sackgassen verrennen wie ich. Natürlich wär’s auch schön, wenn ich von dem einen oder anderen Experten einen Schubs in die richtige Richtung erhalten würde.

Aber worum gehts denn nun überhaupt:

TDD, BDD… WTF?

Wie bereits gesagt, ist BDD als Evolution und nicht etwa als Alternative zu TDD zu verstehen. Kurz gesagt: TDD stellt den Test in den Mittelpunkt, BDD das Verhalten (Behaviour). Auf den ersten Blick erscheinen BDD-Tests recht speziell. Die Klassen- und Test-Namen sind in sprechender Form gehalten. Das ist dann auch gleich einer der Hauptpunkte von BDD: die Sprache. BDD-Tests sollen in einer Sprache definiert sein, die auch ein Fach-Vertreter lesen und verstehen kann.

Hands On

Hier mal ein Beispiel: eine Klasse „Television“ soll getestet werden. Es wird das Verhalten getestet, wenn der Fernseher eingeschaltet wird.

Für das Beispiel wurde xUnit mit den xUnitBddExtensions von Björn Rochel verwendet. Diese beiden Frameworks erlauben es, den BDD-Gedanken bestmöglichst in Code umzusetzen.

   1: [Concern(typeof (Television))]

   2: public class when_Television_turns_on : InstanceContextSpecification

   3: {

   4:     protected override Television CreateSut()

   5:     {

   6:         return new Television();

   7:     }

   8:

   9:     protected override void Because()

  10:     {

  11:         Sut.TurnOn();

  12:     }

  13:

  14:     [Observation]

  15:     public void Should_start_on_channel_one()

  16:     {

  17:         Sut.GetCurrentChannel().ShouldBeEqualTo(1);

  18:     }

  19:

  20:     [Observation]

  21:     public void Should_allow_to_turn_off()

  22:     {

  23:         Sut.TurnOff().ShouldBeTrue();

  24:     }

  25: }

Die Basisklasse InstanceContextSpecification wird vom xUnitBddExtensions-Framework bereitgestellt.

In CreateSut (Sut = System under test), wird also die zu testende Instanz erstellt. Because stellt dann also den eigentlichen Grund des Testens dar, in diesem Falle also die TurnOn-Methode. Danach folgen zwei Observations, die eigentlichen Tests.

Wenn man sich nun die Resultate in einem Testrunner anschaut, sieht man auch, wie sprechend das ganze jetzt daher kommt:

So ein Bericht kann man gut auch jemandem von Fach vorlegen, ohne dass dieser die Stirn runzelt – ok, wenn noch alles rot ist so wie hier, vielleicht schon

Was man auch schön sieht ist, dass sich dieser Bericht wie das Inhaltsverzeichnis einer Spezifikation liest. Die Tests sind also viel näher bei den Anforderungen – auch sprachlich. Mein Eindruck war auch, dass sich Tests so einfacher identifizieren lassen.

AAA

Und gleich nochmal so ein TLA AAA steht für „Arrange Act Assert“ und stellt ein Syntax-Pattern dar. In unserem Beispiel wurde der Test in genau drei solche Teile zerlegt:

1. CreateSut (= Arrange)
2. Because (= Act)
3. Should_x (= Assert)

Der Vorteil dieser Syntax ist, dass die verschiedenen Bereiche des Tests sauber voeinander getrennt sind – so können die Observations auf das wirklich Wesentliche (nämlich das Testen der Verhalten) reduziert werden.

Ansatzweise ist das auch in den bekannten TestSetup-Verfahren von nUnit & Co. umgesetzt – allerdings wird dort das Act und Assert meist vermischt. Die xUnitBddExtensions erlauben hier eine schöne Trennung und saubere Syntax.

Das war ein erster kleiner Einblick in BDD, welcher hoffentlich zum Einstieg einlädt. Ich kann es nur empfehlen. Wer damit starten möchte, dem möchte ich nochmals die xUnitBddExtensions wärmstens ans Herz legen. Die Sourcen umfassen neben dem Framework auch noch zwei Templates für Resharper, welche die Test-Erstellung erleichtert. Ausserdem wurden die Extensions selbst mit BDD-Tests getestet, das heisst man hat dort schon jede Menge guter Samples drin.