Wie in diesem Blog bereits an anderen Stellen erläutert, eignet sich das UIA (UI Automation Framework) sehr gut, um UI-Tests aufzubauen. Wer sich mit dieser Möglichkeit beschäftigt wird aber früher oder später auf das Problem stoßen, dass UIA Support bei WinForms Controls nicht flächendeckend gegeben ist, vor allem bei 3rd Party Controls sieht es da oft eher mau aus.

Ich habe hier beschrieben, wie man mit einem ServerSide Provider diese Lücken selbst schließen kann. Das Standardvorgehen sieht dabei vor, dass man ein eigenes Control erstellt, das man dann von dem Ausgangscontrol ableitet. Diese Vorgehen ist in der Praxis allerdings nicht unproblematisch. Zum einen muss man die abgeleiteten Controls für jedes neue Release der Ausgangscontrols aktualisieren und zum zweiten ist es nicht gerade schön in einer bestehenden Anwendung alle Controls gegen die abgeleitete Variante austauschen zu müssen.

Deshalb möchte ich hier einen alternativen Weg vorstellen. Die Idee beruht darauf, dass die Controls, denen es an Accesibility fehlt jeweils in ein Panel platziert werden und auf diesem Panel dann die entsprechenden Patterns implementiert werden. Das Panel kann die Operationen dann an das Control in seinem Bauch weiterleiten.

Ich habe mal ein Beispiel für Janus Calendar Controls gebaut. Zunächst habe ich mir ein UIA-Panel erstellt, von dem ich dann die weiteren Panels für die spezifischen Controls ableiten kann.

               1:
              using System;

               2:
              using System.Drawing;

               3:
              using System.Security.Permissions;

               4:
              using System.Windows.Automation;

               5:
              using System.Windows.Automation.Provider;

               6:
              using System.Windows.Forms;

               7:  

               8:
              namespace WindowsFormsApplication1

               9: {

               10:
              public
              partial
              class UIAPanel
: Panel, IRawElementProviderSimple

               11: {

               12:
              public UIAPanel()

               13: {

               14:
              this.BackColor
= Color.Yellow;

               15:
              this.Height
= 0;

               16:
              this.Width
= 0;

               17:
              this.AutoSize
= true;

               18: }

               19:  

               20: [PermissionSetAttribute(SecurityAction.Demand,
Unrestricted = true)]

               21:
              protected
              override
              void WndProc(ref Message
m)

               22: {

               23:
              //
0x3D == WM_GETOBJECT
            

               24: Int32
param = 0;

               25:
              if (Int32.TryParse(m.LParam.ToString(), out param))

               26: {

               27:
              if ((m.Msg
== 0x3D) && (param == AutomationInteropProvider.RootObjectId))

               28: {

               29: m.Result
= AutomationInteropProvider.ReturnRawElementProvider(

               30: Handle,
m.WParam, m.LParam, (IRawElementProviderSimple)this);

               31:
              return;

               32: }

               33: }

               34:
              base.WndProc(ref m);

               35: }

               36:  

               37:
              #region IRawElementProviderSimple
Members

               38:  

               39:
              public
              object GetPatternProvider(int patternId)

               40: {

               41:
              if (patternId
== ValuePatternIdentifiers.Pattern.Id)

               42: {

               43:
              return
              this;

               44: }

               45:
              else
            

               46: {

               47:
              return
              null;

               48: }

               49: }

               50:  

               51:
              public
              object GetPropertyValue(int propertyId)

               52: {

               53:
              if (propertyId
== AutomationElementIdentifiers.ClassNameProperty.Id)

               54: {

               55:
              return
              "CalendarPanel";

               56: }

               57:
              else
              if (propertyId
== AutomationElementIdentifiers.ControlTypeProperty.Id)

               58: {

               59:
              return ControlType.MenuBar.Id;

               60: }

               61:  

               62:
              if (propertyId
== AutomationElementIdentifiers.HelpTextProperty.Id)

               63: {

               64:
              return
              "Help
for CalendarPanel";

               65: }

               66:  

               67:
              if (propertyId
== AutomationElementIdentifiers.AutomationIdProperty.Id)

               68: {

               69:
              return
              this.Name; 

               70: }

               71:  

               72:
              if (propertyId
== AutomationElementIdentifiers.IsEnabledProperty.Id)

               73: {

               74:
              return
              true;

               75: }

               76:  

               77:
              else
            

               78: {

               79:
              return
              null;

               80: }

               81: }

               82:  

               83:
              public IRawElementProviderSimple
HostRawElementProvider

               84: {

               85: get

               86: {

               87:
              return AutomationInteropProvider.HostProviderFromHandle(Handle);

               88: }

               89: }

               90:  

               91:
              public ProviderOptions
ProviderOptions

               92: {

               93: get

               94: {

               95:
              return ProviderOptions.ServerSideProvider;

               96: }

               97: }

               98:  

               99:
              #endregion
            

               100:  

               101: }

               102: }

Dieses Panel stellt einen ServerSide Provider zur Verfügung. Wir können nun von diesem Control ableiten und ein entsprechendes Pattern, z.B. das SetValue Pattern implementieren:

               1:
              using System;

               2:
              using System.Windows.Automation.Provider;

               3:
              using System.Windows.Forms;

               4:  

               5:
              namespace WindowsFormsApplication1

               6: {

               7:
              public
              partial
              class CalendarPanel
: UIAPanel, IValueProvider

               8: {

               9:
              private Janus.Windows.Schedule.Calendar
control;

               10:
              public Janus.Windows.Schedule.Calendar
Control

               11: {

               12: get

               13: {

               14:
              if (control
== null)

               15: {

               16:
              if (this.Controls.Count
> 0 && this.Controls[0].GetType() == typeof(Janus.Windows.Schedule.Calendar))

               17: control
= (Janus.Windows.Schedule.Calendar)this.Controls[0];

               18: }

               19:
              return control;

               20: }

               21: }

               22:  

               23:
              #region IValueProvider
Members

               24:  

               25:
              public
              bool IsReadOnly

               26: {

               27: get 

               28: {

               29:
              return
              false;

               30: }

               31: }

               32:  

               33:
              public
              void SetValue(stringvalue)

               34: {

               35:
              this.BeginInvoke((MethodInvoker)delegate()

               36: {

               37: DateTime
date = DateTime.Parse(value);

               38: Control.SelectionRange
= new Janus.Windows.Schedule.DateRange(date, date);

               39: });

               40: }

               41:  

               42:
              public
              string Value

               43: {

               44: get 

               45: {

               46:
              return Control.SelectionRange.End.ToShortDateString(); 

               47: }

               48: }

               49:  

               50:
              #endregion
            

               51: }

               52: }

Wenn wir nun das Calendar_Control nicht direkt auf unserer Form platzieren, sondern in einem solchen CalendarPanel ablegen, können wir eine Automatisierung über die UIA gegen dieses Panel implementieren. Was nun noch optimiert werden soll, ist dass die ganzen Controls nicht händisch in die jeweiligen Panels platziert werden sollen, sondern dies soll nach Möglichkeit automatisiert werden. der Ansatz hierbei ist, dass alle Controls auf der Form beim Laden untersucht werden und für die gewünschten Controls dynamisch entsprechende Panels erzeugt werden sollen, in die dann die Controls platziert werden. Dieser Ansatz bietet zudem den Vorteil, dass man die UIA-Panels nur dann nutz, wenn man UI-Test ausführen möchte. Bei der Release-Version sind diese dann nicht enthalten. Zwar unterscheidet sich dadurch Release und Test-Version geringfügig, jedoch sollten diese Implikationen vernachlässigbar sein, vor allem dann, wenn beim Entwickeln komplett auf die Panels verzichtet wird und diese wirklich nur für die UI-Tests genutzt werden.

Der Code dazu sieht dann so aus:

               1:
              private
              void PlaceControlsIntoPanel(Control.ControlCollection
controls)

               2: {

               3: Panel
uiaPanel;

               4:  

               5:
              foreach (Control
automationControl in controls.OfType<Control>().ToList())

               6: {

               7:
              switch (automationControl.GetType().ToString())

               8: {

               9:
              case
              "Janus.Windows.CalendarCombo.CalendarCombo":

               10: {

               11: uiaPanel
= new CalendarComboPanel();

               12:
              break;

               13: }

               14:
              case
              "Janus.Windows.Schedule.Calendar":

               15: {

               16: uiaPanel
= new CalendarPanel();

               17:
              break;

               18: }

               19:
              default:

               20: {

               21:
              if (automationControl.HasChildren)

               22: {

               23: PlaceControlsIntoPanel(automationControl.Controls);

               24: }

               25:
              continue;

               26: }

               27: }

               28: uiaPanel.Name
= "p_" + automationControl.Name;

               29: uiaPanel.Top
= automationControl.Top;

               30: uiaPanel.Left
= automationControl.Left;

               31: uiaPanel.Controls.Add(automationControl);

               32: automationControl.Top
= 0;

               33: automationControl.Left
= 0;

               34: controls.Add(uiaPanel);

               35: }

               36: }

Wird die Anwendung dann inkl. Test-Client ausgeführt, sieht das so aus:

Im Juni werden wir beim EMEA-Meeting der Team System User Group Virtual Edition Ed Blankenship als Sprecher haben. Ed ist MVP für Team System und Release Manager bei Infragistics, dem führenden Hersteller von UI-Komponenten. Er wird in seinem Vortrag über die Erfahrungen bei der Einführung von VSTS bei Infragistics berichten. Dabei werden die verschiedenen Bereiche wie Versionsverwaltung, Build Management, Work Item tracking, das Management globaler Teams, automatisiertes Testen und vieles mehr aus einer Anwendersicht beleuchtet. Ein wirklich sehenswerter Erfahrungsbericht aus der Praxis.

Weitere Informationen unter www.tsug-ve.com.

Im Team Foundation Server werden Änderungen an den Inhalten der Workitems in einer Historie festgehalten. Diese Historie kann man auf jedem einzelnen Workitem einsehen.

Mit einem kostenlosen Excel-Addin können diese Auswertungen auch massenhaft durchgeführt und so über ganze Projekte Auswertungen über die Historie erstellt werden. Dazu wird zunächst ein Zeitraum und ein Intervall ausgewählt (alternativ kann man auch einen bestimmten Zeitpunkt wählen):

Nun werden für jeden gewählten Zeitpunkt die Work Items in dem jeweiligen Zustand in eine Excel-Tabelle eingetragen. Diese kann nun sehr schön über eine Pivot-Tabelle oder ein Pivot-Chart ausgewertet werden um so den zeitlichen Verlauf bestimmter Kennwerte abzubilden.

Natürlich lassen sich solche Ergebnisse auch über das DataWarehouse im TFS ermitteln, jedoch besitzt dieses Tool zwei Vorteile:

1. Es ist wesentlich einfacher zu bedienen und übersichtlicher, so dass damit auch Ad-Hoc Reporting für Anwender möglich wird.
2. Es grift auf alle Workitem-Daten zurück, nicht nur auf die, die im DataWareHouse konfigurierten. Einzige Ausnahme sind Links und Attachments, die in beiden Varianten nicht Teil der Historie sind.

Weitere Informationen und den kostenlosen Download gibtes unter http://www.alm-tools.de/?Product=5

Ein Video das die Fuinktionsweise des Tools demonstriert kann hier agezeigt werden.

Eigentlich versuche ich meinen Blog weitgehend werbefrei zu halten. Diesesmal möchte ich aber doch kurz auf die Seite www.alm-tools.de hinweisen, die mein Arbeitgeber artiso betreibt. Hier haben wir vor Kurzem eine Reihe neuer Tools rund um das Thema TFS und ALM (Application Lifecycle Management) veröffentlich, zum Teil kostenlos. Zudem gibt es hier inzwischen auch ein kleines Archiv mit Videos rund um das Thema das wir kontinuierlich ausbauen.

Mein Kollege Mark Bulmahn hat in einem Screencast ein Problem näher untersucht, das beim Merge in der TFS Source Countrol auftreten kann. Dabei geht es vor allem darum, dass Verschiebe-Operationen im Visual Studio Solution Explorer in der Source Control nicht als Verschiebe-Operation sondern als Delete und Add ausgeführt wird. Das führt dann zu Problemen bei einem späteren Merge.In dem Screencast sieht man, wie dieses Problem vermieden und auch wieder repariert werden kann.

Wenn schon mit Pre-Releases arbeiten, dann richtig habe ich mir gedacht und versucht den Team Foundation Server 2010 Beta 1 auf dem Windows 2008 Server R2 RC zu installieren. Nach einer kurzen Recherche im Internet bin ich auf diesen Blog-Post gestoßen. Mit den Informationen dort ist es mir tatsächlich gelungen, den TFS 2010 Beta1 und VSTS 2010 Beta1 auf dem Win2008R2 RC zu installieren. Damit komme ich nun auch auf meiner Demo-Maschine in den Genuss der Desctop-Experience von Win2008R2 :-)

Im Mai haben wir bei der TSUG-VE Ian Ceicis als Sprecher zum Thema Projekt Management mit TFS 2010. Er wird in seinem Vortrag die Neuerungen rund um das Workitem-Tracking in TFS 2010 vorstellen.

Want to get the skinny on the latest enhancements coming in TFS 2010, come see demos of the updated MSF Agile template, the new Agile workbooks, the new Excel reports, and the Microsoft Project client improvements such as Hierarchical work items, rollups, and project summary tasks. This session will be packed with demos from  Beta 1 and will be a great way to start getting familiar with the new tools coming in 2010. Bring your hardest questions, join the conversation, and walk away with the ability to see how your next project will run smoothly if you start using TFS 2010.

This month's meeting is being presented by Ian Ceicys.  Ian is a member of Microsoft's Global ALM Practice and an active member of the VSTS Rangers.

 

Das Treffen findet am Donnerstag, 21.05.2009 um 19:00 statt.

Weitere Infos unter http://www.tsug-ve.com

Unter http://msdn.microsoft.com/en-us/library/dd831853(VS.100).aspx steht inzwischen auch die Dokumentation für das .Net Framework 4 Beta 1 und Visual Studio 2010 Beta 1 zur Verfügung. Für die Beta 1 wird es nur eine Online-Version der Dokumentation geben, eine lokale Installation wird erst mit einer späteren Version verfügbar sein, was sicher bei einer Beta-Dokumentation auch Sinn macht.

Nachdem es bisher nur Gerüchte gab, nun ist es offiziell. Visual Studio 2010 Beta 1 wird noch heute für MSDN-User verfügbar sein. Für die Öffentlichkeit gibt es den Download dann ab Mittwoch.

Diesmal aus einer verlässlichen Quelle (Soma Somasegar, Corporate Vice President Microsofts)

Visual Studio 2010 and .NET FX 4 Beta 1 ships!

Update: Ich habe die Bits inzwischen runtergeladen. Da haben die Jungs wirklich noch einiges reingepackt gegenüber den früheren CTPs.

    &  

Mit der Version 3 des Design-Tools für WPF und SilverLight, Expression Blend bekommt nun endlich die Unterstützung für den Team Foundation Server um die Source-Dateien in der Versionsverwaltung abzulegen. Hierzu muss ein entsprechendes Hotfix installiert werden. Dann hat man im Project-View zusätzliche Icons die den Auscheck-Status der Dateien anzeigt und im Kontext-Menü befinden sich entsprechende Kommandos für die Versionsverwaltung.

Hinweis: Damit das beim ersten Start auch wirklich funktioniert, muss man im Visual Studio den Team Explorer wenigstens einmal gestartet haben und dort den Server registrieren. Sonst bekommt man die Meldung "Unable to determine workspace" im Expression Blend.

Beim Checkin ist auch die sehr nützliche Funktion zur Verknüpfung von Workitems beim Checkin verfügbar.

Damit kann Expression Blend nun endlich in den Entwicklungs-Prozess von Software-Anwendungen integriert werden und steht nicht nur als separates Design-Tool bereit.

Nach rund einer Woche ist bereits die Hälfte der Plätze beim .Net Open Space Süd 2009 vergeben. Stand heute haben wir 33 Anmeldungen und es sind ein paar hochkarätige .Net Experten darunter. Wer also noch dabei sein will, sollte nicht zögern, sondern sich gleich auf die Teilnehmerliste eintragen.

Wir sehen uns am 11/12. Juli in Ulm!

Auf einer neuen TFS-Instanz hatte ich eben ein seltsames Phänomen. Ich konnte das erste Team-Projekt problemlos anlegen. Dazu verwendete ich einen Team_Explorer mit einer Visual Studio Shell Installation auf dem Server. Als ich allerdings das zweite Projekt anlegen wollte, kam eine Fehlermeldung, dass mir die Berechtigungen auf den Reporting Services fehlen. Seltsam nur, dass es beim ersten Projekt geklappt hat und dazwischen nichts geändert wurde. Mit einem kleinen Trick konnte ich dann doch ein zweites Projekt anlegen, nämlich indem ich alle Projekte aus dem Team-Explorer entfernt habe. Dann konnte ich wieder genau ein neues anlegen.

Die eigentliche Lösung für das Problem brachte aber die Installation des SP1 auf dem Server. Dabei ist zu beachten, dass das SP1 für den Team-Explorer nicht Bestandteil des Team Foundation Server SP1 ist, sondern des Visual Studio SP1. Also das Visual Studio SP1 installiert und danach lief es wunderbar.

Letzte Woche habe ich bei der .Net Developer-Group Ulm einen Vortrag zum Thema “10 Gründe warum Software-Projekte fehlschlagen – und was hilft ALM"?” gehalten. Es gab zu diesem Vortrag eine reihe interessanter Diskussionen. Die Folien gibt’s hier zum herunterladen:

Bei der TeamConf handelt es sich um eine Konferenz mit dem Focus auf Themen rund um VSTS und TFS. Da durfte ich natürlich nicht fehlen ;-)

Leider war mein Vortrag der letzte der Konferenz und dazu noch parallel zum VSTS 2010 Vortrag von Christian Binder. Dennoch fand sich eine interessierte Runde zum Thema “Requirements Management in leichtgewichtigen Prozessen” zusammen. Hier noch meine Folien zum Download:

Termin: 19.05.2009 - 18:00 Uhr

Veranstaltungsort:

Referent:

Vortrag:

As Developers, when we see a given demand, we always think on how to solve on a very imperative way (first do this, then this, finally that). Why not starting thinking on a more functional level, where we do not need to break one given task into so small imperative steps? This session will introduce Microsoft's new language F#, a typed functional programming language for the .NET Framework that combines the succinctness, expressivity and compositionality of functional programming with the runtime support, libraries, interoperability, tools, and object model of .NET. We'll take a look at why Microsoft is adding the language to the suite of those available on .NET and at some of simple language constructs that make programming in F# a dream.

Pedro Castelo Branco Lourenço is a Brazilian guy that moved into Germany to work as Innovation manager at Savcor IT GmbH(http://www.savcor.de), MVP (Microsoft Most Valuable Professional) on C#, Microsoft Certified Professional Developer(Web & Windows), independent consultant to companies that build software using .Net platform, speaker in some well known technical events such as Tech Ed 2005, 2008(Brazil), Community Days, Developers On The Road, União.Net. Bachelor degree in computer science, member of moderator’s team of .Net Raptors community (www.dotnetraptors.com.br). During his free-time he is studying German to make his family life easier!

Im zweiten Teil wurde anhand eines kleinen Demos die konkrete Implementierung von WCF-Anwendungen erläutert. Es wurde ein Chat-System auf Basis der WCF erstellt. Das Demo gibt es hier zum Download. Außerdem möchte ich hier noch auf eine Einführung in die WCF hinweisen die man hier findet

Beim ersten Termin wurden die Grundlagen zu verteilten Anwendungen im allgemeinen und der WCF im speziellen vermittelt.

Eines der coolsten Features in Windows 7 ist für mich der Problem Steps Recorder. Damit lassen sich Benutzeraktionen aufzeichnen und als MHT-File mit Screenshoots ausgeben. Diese Funktion eignet sich sehr gut um z.B. Installationsanleitungen oder auch Dokumentationen von Testdurchläufen zu erstellen. Hierzu wird einfach der Problem Steps Recorder über den Befehl PSR gestartet.

Nach einem Klick auf Start Record werden nun die Benutzeraktionen aufgezeichnet. Heraus kommt dann ungefähr so etwas:

Problem Step 15: User left double click on "Name (editable text)" in "WorkItem_Manager_Open_1.0.0_Installer[1]"

Previous Next

Problem Step 16: User left click on "Run (push button)" in "Open File - Security Warning"

Previous Next

Problem Step 17: User left click on "Next > (push button)" in "artiso Workitem Manager Open"

Diese Aufzeichnungen funktionieren sowohl mit Web- als auch Windows-Anwendungen. Und natürlich können die erzeugten MHT-Files in Word oder anderen Editoren noch bearbeitet werden. So können z.B. überflüssige Zwischenschritte entfernt und Texte editiert werden. Es können auch währen des Aufzeichnungsvorgangs Kommentare erfasst und diesen ein bestimmter Bildausschnitt zugeordnet werden.

Grade erst wurden die EMEA-Meetings der Team System User Group Virtual Edition ins Leben gerufen, schon können wir mit einem Highlight aufwarten. Für unser April-Meeting konnten wir Brian Harry als Sprecher gewinnen. Brian wird über die Internal Adoption von VSTS sprechen. Brian ist Technical Fellow und Manager der Product Unit für den team Foundation Server.

Also gleich als Mitglied registrieren und am 16. April dabei sein!

Weitere Informationen zum Meeting gibt’s unter www.tsug-ve.com.

Der Tatsache, dass Testen eine wichtige Bedeutung in der Software-Entwicklung hat, trägt Microsoft ja bereits seit einiger Zeit Rechnung indem eine spezielle Edition des Visual Studio für Tester generiert wurde. Diese Edition besitzt umfangreiche Funktionenzu verschiedenen Test-Methoden. Das Ranger-Team hat nun einen Quick Reference Guide veröffentlicht der auf 83 Seiten diese Funktionen beschreibt und verschiedene Best Practices anbietet. Hierbei sind die Erfahrungen eingeflossen, die Service Labs, ein großes Test-Center, bei der Adaption von Team Test gemacht hat. Das Dokument enthält viele wertvolle Hinweise, wie VSTT in der Praxis eingesetzt und individuell erweitert werden kann.

Definitiv lesenswert für jeden, der etwas mehr über dieses Toolset erfahren möchte.

Download VSTT 2008 Quick Reference Guide

Das Thema Test Driven Development oder auch Test First Developent gewinnt immer mehr an Beachtung. Keine Konferenz, keine Zeitschrift, kein Sprecher der was auf sich hält kommt um das Thema herum. Doch nach dem überzeugenden Vortrag sitzt man zu Hause im Büro vor einem leeren Project und wie nun anfangen? Hier scheitern bereits die ersten, weil entsprechende Publikationen oft zwar die Vorteile ausführlich schildern, aber nicht den Einstieg darstellen. Deshalb möchte ich hier einen entsprechenden Einstieg geben und mit einem wirklich leeren Projekt beginnen.

Die Theorie um TDD will ich hier einfach weglassen. Hierzu gibt es bereits Informationen genug. Und wir werden verschiedene Vereinfachung vornehmen, über die Profis etwas die Nase rümpfen werden, aber damit erhalten wir ein einfaches und praktikable Einstiegsszenario.

Zum Einsatz kommen hierbei die Testfunktionen von Visual Studio 2008 die ab der Professional Edition enthalten sind. Wir beginnen mit einer komplett leeren Solution.

Die Frage, die nun im Raum steht, ist: Wie schreibe ich einen Test ohne eine Methode zu haben. Ein Unit-Test besteht ja im Prinzip darin, dass wir eine Methode aufrufen und den Rückgabewert mit einem Erwartungswert vergleichen. Der Test wird aber nicht einmal kompilieren, solange die Methode nicht definiert ist. Der Workaround an dieser Stelle sieht dann oft so aus, dass man von der Methode und ihrer Klasse erst einmal einen Stub anlegt der im wesentlichen eine “ThrowNotImplemented”-Exception wirft. Damit haben wir aber eigentlich schon mehr implementiert als nach dem TDD uns lieb ist.

Ein etwas eleganterer Ansatz geht über die Definition von Interfaces. Diese Vorgehensweise eignet sich besonders gut bei einer komponentenorientierten Architektur mit einem Contract First Ansatz. Dabei werden die Schnittstellen der einzelnen Komponenten erst über Contracts (Interfaces) beschrieben bevor diese implementiert werden. Den TDD-Ablauf Rot > Grün > Refactor erweitern wir ein wenig. Damit ergibt sich folgende Abfolge:

Contract definieren > Test implementieren > Rot > Funktion implementieren > Grün > Refactor

D.h. wir erstellen in einem ersten Schritt einen Contract (genau genommen machen wir damit kein TDD sondern ein Test First. Beim TDD ist der Test das erste was erstellt werden muss, aber das ist in meinen Augen eher Haarspalterei, so funktioniert es einfach in der Praxis). Wir erstellen ein neues ClassLibrary-Projekt und erstellen dort ein Interface.

               1:
              namespace Contracts

               2: {

               3:
              public
              interface IOrderCalculator

               4: {

               5:
              decimal CalculateShippinghCosts(decimal sum, decimal freeShippingMin, decimal shippingCosts);

               6: }

               7: }

Wir wollen hier ein überschaubares, aber auch nicht zu triviales Beispiel verwenden. Die Methode CalculateShippingCosts soll zu einem gegebenen Rechnungsbetrag Versandkosten hinzuaddieren, wenn ein bestimmter Mindestbetrag nicht erreicht ist. So damit haben wir den Contract erstellt. Nun wollen wir einen Test dazu erstellen. Das geht am schnellsten durch einen Rechts-Klick auf die Methode und dann “Create Unit-Tests”.

Hier wird standardmäßig ein neues Test-Projekt angelegt. Darin wird ein entsprechender Unit-Test generiert.

               1: [TestMethod()]

               2:
              public
              void CalculateShippinghCostsTest()

               3: {

               4: IOrderCalculator
target = CreateIOrderCalculator(); // TODO: Initialize
to an appropriate value

               5: Decimal
sum = new Decimal(); //
TODO: Initialize to an appropriate value

               6: Decimal
freeShippingMin = new Decimal(); //
TODO: Initialize to an appropriate value

               7: Decimal
shippingCosts = new Decimal(); //
TODO: Initialize to an appropriate value

               8: Decimal
expected = new Decimal(); //
TODO: Initialize to an appropriate value

               9: Decimal
actual;

               10: actual
= target.CalculateShippinghCosts(sum, freeShippingMin, shippingCosts);

               11: Assert.AreEqual(expected,
actual);

               12: Assert.Inconclusive("Verify
the correctness of this test method.");

               13: }

Damit können wir den Test bereits zum ersten mal ausführen und er geht wie erwartet auf Rot. Aber Moment, wie funktioniert das. Wie kann der Test eine Methode auf einem Interface aufrufen? Es gibt ja noch keine Implementierung des Interfaces und ein Interface selbst lässt sich ja nicht instanziieren. Hier baut Visual Studio einen kleinen Workaround. In Zeile 4 im obigen Code sieht man, dass eine Instanz des target-Objektes über die Methode CreateIOrderCalculator() erstellt wird. Diese Methode wollen wir mal etwas genauer anschauen.

               1:
              internal
              virtual IOrderCalculator
CreateIOrderCalculator()

               2: {

               3:
              //
TODO: Instantiate an appropriate concrete class.
            

               4: IOrderCalculator
target = null;

               5:
              return target;

               6: }

Hier wird das Objekt einfach mit null initialisiert. Ein einfacher, aber wirkungsvoller Workaround. Damit erreichen wir unser Ziel, dass der Test kompiliert aber fehlschlägt. Nach der Implementierung ersetzen wir das null einfach durch die entsprechende Initialisierung. Damit können wir nun unsere Testcases Implementieren.

               1: [TestMethod()]

               2:
              public
              void CalculateShippinghCosts_Sum_Below_FreeShippingMin()

               3: {

               4: IOrderCalculator
target = CreateIOrderCalculator();

               5: Decimal
sum = 1;

               6: Decimal
freeShippingMin = 10;

               7: Decimal
shippingCosts = 5;

               8:
              //
We are below min, so we have to add shippingCosts
            

               9: Decimal
expected = 6;

               10: Decimal
actual;

               11: actual
= target.CalculateShippinghCosts(sum, freeShippingMin, shippingCosts);

               12: Assert.AreEqual(expected,
actual);

               13: }

               14:  

               15: [TestMethod()]

               16:
              public
              void CalculateShippinghCosts_Sum_Above_FreeShippingMin()

               17: {

               18: IOrderCalculator
target = CreateIOrderCalculator();

               19: Decimal
sum = 20;

               20: Decimal
freeShippingMin = 10;

               21: Decimal
shippingCosts = 5;

               22:
              //
We are above min, so we don't add shippingCosts
            

               23: Decimal
expected = 20;

               24: Decimal
actual;

               25: actual
= target.CalculateShippinghCosts(sum, freeShippingMin, shippingCosts);

               26: Assert.AreEqual(expected,
actual);

               27: }

               28:  

               29: [TestMethod()]

               30:
              public
              void CalculateShippinghCosts_Sum_Equal_FreeShippingMin()

               31: {

               32: IOrderCalculator
target = CreateIOrderCalculator();

               33: Decimal
sum = 10;

               34: Decimal
freeShippingMin = 10;

               35: Decimal
shippingCosts = 5;

               36:
              //
We are equal min, so we don't add shippingCosts
            

               37: Decimal
expected = 10;

               38: Decimal
actual;

               39: actual
= target.CalculateShippinghCosts(sum, freeShippingMin, shippingCosts);

               40: Assert.AreEqual(expected,
actual);

               41: }

Damit haben wir unser Szenario ausreichend beschrieben. Wir können nun an die Implementierung gehen.Dazu legen wir ein neues Projekt an in dem wir eine Klasse definieren die wir von unserem Interface ableiten.

               1:
              namespace Components

               2: {

               3:
              public
              class cOrderCalculator
: IOrderCalculator

               4: {

               5:
              public
              decimal CalculateShippinghCosts(decimal sum, decimal freeShippingMin, decimal shippingCosts)

               6: {

               7:
              //
If sum is greater than Min then don't add shipping costs
            

               8:
              if (sum
> freeShippingMin)

               9:
              return sum;

               10:
              else
            

               11:
              //
else add shipping costs
            

               12:
              return sum
+ shippingCosts;

               13: }

               14: }

               15: }

Nun müssen wir unbedingt noch daran denken, die Initialisierung des Testobjektes in unserer Testmethode anzupassen.

               1:
              internal
              virtual IOrderCalculator
CreateIOrderCalculator()

               2: {

               3: IOrderCalculator
target = new cOrderCalculator();

               4:
              return target;

               5: }

Nun können wir die Tests ausführen.

Oh, ein Test schlägt fehl. Bei genauerer Betrachtung stellen wir fest, dass wir bei der Implementierung den Fall dass die Summe gleich der Grenze ist nicht richtig berücksichtigt haben. Also hat sich hier der TDD-Ansatz schon bewährt und wir können den Fehler beheben. Damit sind alle Tests grün und wir können weiter fortfahren. Wir könnten nun z.B. auf unserem Interface weitere Methoden definieren und dafür Tests anlegen.

Also eigentlich gar nicht so schwer das mit dem TDD, oder? Freue mich auf euer Feedback.

Die Solution gibt es zum Download.

Happy Testing!

Letzte Woche war ich als Trainer beim Team System Camp. Eine wirklich bemerkenswerte Veranstaltung! Schon der Veranstaltungsort selbst war bemerkenswert. Das Häckers Kurhotel in Bad Ems stellte einen durchaus würdigen Rahmen für die Veranstaltung dar und auch der Seminarraum hatte durchaus Stil:

Die Verpflegung war dem Ambiente angemessen, Mittags und Abends ein vorzügliches 3-Gänge-Menü und auch das Rahmenprogramm passte. Mit Kart-Fahren, Casino-Besuch und weiteren Aktivitäten konnte ein paar Momente entspannt werden. Das war auch dringend nötig. Denn trotz all dieser Annehmlichkeiten kamen natürlich die Inhalte nicht zu kurz. Zwei Trainer auf 5 Teilnehmer ist sicher schon ein ungewöhnlicher Schnitt. Aber dass die Trainings von 9:00 Uhr bis 23:00 gehen ist schon heftig. Also wurde nach dem Kart-Fahren noch was gegessen und dann ging’s im Seminar-Raum weiter. So konnten die Teilnehmer sicher einen sehr guten Überblick über den Team Foundation Server und VSTS bekommen. Und durch die kleine Gruppengröße konnte auch auf individuelle Fragen ausführlich eingegangen werden.

Mir hat’s jedenfalls viel Spaß gemacht und bin beim nächsten mal gerne wieder dabei.

Die Integration von Visual Studio 2005 / 2008 mit dem TFS ist ideal gelöst. Jedoch gibt es auch noch andere Entwicklungs-Plattformen die keine direkte Integration mit dem Team-Explorer erlauben wie z.B. ältere Visual Studio Versionen und leider auch immer noch das SQl Server Management Studio. Diese IDEs überstützen doch recht häufig den sog. MSSCCI-Standard und es gibt bereits seit längerer Zeit einen entsprechenden MSSCCI-Provider für den TFS 2008. Dieser hatte bisher immer noch den nachteil, dass er reine Sourcecontrol Features unterstützt hat und z.B. das Verknüpfen von Workitems beim Checkin nicht möglich war. In der neuesten Version ist dies nun auch möglich und somit ist auch bei IDEs die den Team Explorer nicht integrieren ein komfortables Arbeiten mit dem TFS möglich. Ich habe hier mal ein Beispiel für das SSMS 2008.

Zunächst muss der TFS MSSCCI-Provider unter Optionen eingestellt werden.

Legt man nun ein Datenbankprojekt an, dann kann man das in gewohnter Art und Weise mit der Source Control verbinden und man erhält Fenster “Pending Checkins”.

Führt man hier nun den Checkin aus, kommt der aus dem Team-Explorer bekannte Dialog

Hier können nun z.B. Checkin-Kommentare angegeben oder Workitems verknüpft werden.

Sogar die Checkin-Plicies funktionieren hier wie gewohnt.

Damit ist ein komfortables und problemloses Arbeiten auch mit solchen Umgebungen möglich, die den Team-Explorer nicht direkt integrieren. Und damit wieder ein Grund mehr, nun endlich auf den TFS zu setzen und SourceSafe und Konsorten endlich in Rente zu schicken.

Bei der Team System Usergroup – Virtual Edition (TSUG-VE) handelt es sich um eine weltweite Online-Community die sich auf die Themen Visual Studio Team System und Team Foundation Server konzentriert hat. Die Treffen finden dabei zeitgleich in SecondLife und LiveMeeting statt. SecondLife bietet den Vorteil, die sozialen Aspekte einer Community besser in der Online-Welt abzubilden, LiveMeeting wird als Präsentationssystem genutzt. Die virtuellen Treffen unterscheiden sich vom Ablauf und Inhalt kaum von denen entsprechender Offline-Communities. Während und nach den Vorträgen können ganz normal Fragen gestellt werden. Die Vorträge werden aufgezeichnet und stehen Mitgliedern im nachhinein im LiveMeeting-Portal zur Verfügung.

Um die Vortragszeiten für die Teilnehmer rund um den Globus komfortabler zu gestalten, wurde nun eine europäische Sektion der TSUG-VE ins Leben gerufen. Diese Sektion organisiert Meetings in einer komfortablen Zeit für die EMEA-Zone (19:00 Uhr deutscher Zeit). Natürlich steht den Mitgliedern jederzeit die Möglichkeit offen, an den Treffen der US-Sektion oder für den Bereich Asian-Pacific (momentan im Aufbau) teilnehmen zu können oder die Videos nachträglich abzurufen ohne sich hierfür separat registrieren zu müssen. Alle Treffen werden in englischer Sprache abgehalten.

Die Leitung der EMEA-Zone habe ich übernommen und würde mich freuen, in Zukunft mehr Mitglieder aus dem Europa begrüßen zu dürfen. Kritik und Anregungen zur Organisation sind sehr willkommen, da wir im Moment noch dabei sind Erfahrungen im Betreiben einer Online-Community sammeln.

VISfire sit eine Charting-Komponente für Silverlight und WPF. Das coole daran ist, dass die Charts animiert werden können.  Einen schnellen Eindruck bekommnt man über die Silverlight Chart Gallery. Die componente ist unter GPL und einer kommerziellen Lizenz verfügbar.

Wie so oft lautet die Antwort es kommt darauf an. Un hier bietet die Seite ShineDraw eine gute Vergleichsmöglichkeit. In der Gallery befinden sich zahlreiche Beispiele die sowohl in Silverlight als auch in Flash implementiert sind. Da kann man nicht nur das Ergebnis in beiden Varianten vergleichen sondern auch den Code der in der jeweiligen Technologie erforderlich ist. Darüber hinaus kann man sich den einen oder anderen effekt abschauen und sieht auch gleich wie der implementiert wird. Der Quellcode ist unter der GNU General Public License, Version 3 bereitgestelt.

http://www.shinedraw.com/flash-vs-silverlight-gallery/

Die Initiative Clean Code Developer (CCD) (http://www.clean-code-developer.de/) hat sich zum Ziel gesetzt bestimmte Grundsätze bei der Entwicklung von Software bei den Entwicklern besser zu verankern. Bei diesen Grundsätzen handelt es sich um Prinzipien, Regeln und Praktiken deren Einhaltung zu qualitativ höherwertigem Code führt. Grundsätzlich ist eine Schrittweise Einführung dieser Prinzipien, regeln und Praktiken unterteilt in Grade vorgesehen. Zu jedem Grad gibt es ein farbiges Armband, das den Träger zum Einen als CCD ausweist und ihn zudem stets daran erinnert diese Grundsätze in seiner täglichen Arbeit zu befolgfen. Mit Sefan Lieser und Ralf Westphal stehen hinter diesem Projekt zwei ausgewiesene Experten.

Die .Net Developer-Group Ulm (www.dotnet-ulm.de) möchte diese Aktion unterstützen und ruft seine Mitglieder auf sich zu beteiligen. Beim nächsten Treffen am 19.03.09 wird diese Aktion im Detail vorgestellt und es besteht die Möglichkeit die Armbänder zu einem vergünstigten Preis zu erwerben. Zudem ist angedacht, dass sich die beteiligten regelmäßig nach den UG-Meetings austauschen und gegenseitig über Erfahrungen berichten und die Konzepte des CCD miteinander diskutieren.

Natürlich freue ich mich auf eine rege Teilnahme und natürlich sind Gäste gerne willkommen.

Nähere Infos unter http://www.dotnet-ulm.de/Cleancodedeveloper.aspx

Mit diesem Sidebar-Gadget kann man sich den Status seiner Build schnell und einfach anzeigen lassen.

Jim Lamb : Team Build Monitor – Vista Sidebar Gadget

Bei unserem nächsten Treffen am 19.03 haben wir Gregor Biswanger und Robert Walter zu Gast. Diese werden in ihrem Vortrag verschiedene Aspekte zu Test Driven Development beleuchten. Nähere Infos gibts hier:

http://www.dotnet-ulm.de/Treffen.aspx#19032009

Am 16.03.09 geht ein neuer Webcast von mir online mit dem Thema "Team Build mit Custom Build Tasks erweitern". Ich möchte hier schon mal die entsprechenden Infos veröffentlichen.

In TeamBuild lassen sich eigene Build-Task integrieren. Diese können sehr einfach erstellt werden. Hierzu wird eine Klasse erstellt und diese von Task abgeleitet. Im folgenden Beispiel wird ein Build-Task erstellt, der im Rahmen des Builds die Version der Anwendung setzt. Und zwar soll hier die Build-Nummer in der Versionsnummer der Assembly abgebildet werden. Dies bietet Vorteile, wenn zu einer bestimmten Anwendungsversion der entsprechende Build identifiziert werden soll.

               1:
              using System;

               2:
              using System.Collections.Generic;

               3:
              using System.Text;

               4:
              using Microsoft.Build.Utilities;

               5:
              using Microsoft.Build.Framework;

               6:  

               7:
              namespace Artiso.BuildTasks

               8: {

               9:
              ///
<summary>
            

               10:
              ///
Creates a AssemblyVersion out of a BuildNumber
            

               11:
              ///
</summary>
            

               12:
              ///
<remarks>
            

               13:
              ///
AssemblyVersion.Minjor and AssemblyVersion.Minor will be defined fiexed in
            

               14:
              ///
the Build-Script. If the BuildNumber is Dev_Versioning_20090305.4 we use 
            

               15:
              ///
two digit year and month for AssemblyBuildNumber and day and 3 digit BuildRevision
            

               16:
              ///
for AssemblyRevision. BuildRevisio 
            

               17:
              ///
</remarks>
            

               18:
              ///
<example>
            

               19:
              ///
Dev_Versioning_20090305.4 => xx.yy.0903.05004
            

               20:
              ///
</example>
            

               21:
              public
              class ExtractRevision
: Task

               22: {

               23:
              #region [rgn]
Fields(3)

               24:
              private
              string buildRevision;

               25:
              private
              string buildVersion;

               26:
              private
              string buildNumber;

               27:
              #endregion
            

               28:  

               29:
              #region [rgn]
Properties(3)

               30:
              ///
<summary>
            

               31:
              ///
Input Build Number
            

               32:
              ///
</summary>
            

               33: [Required]

               34:
              public
              string BuildNumber

               35: {

               36: set
{ buildNumber = value; }

               37: }

               38:  

               39:
              ///
<summary>
            

               40:
              ///
Returns the sortened date of the build
            

               41:
              ///
</summary>
            

               42: [Output]

               43:
              public
              string BuildVersion

               44: {

               45: get
{ return buildVersion; }

               46: }

               47:  

               48:
              ///
<summary>
            

               49:
              ///
Returns the Build Revision (number of build at this day
            

               50:
              ///
</summary>
            

               51: [Output]

               52:
              public
              string BuildRevision

               53: {

               54: get
{ return buildRevision; }

               55: }

               56:
              #endregion
            

               57:  

               58:
              #region [rgn]
Methods(1)

               59:
              public
              override
              bool Execute()

               60: {

               61: buildVersion
= "0";

               62: buildRevision
= "0";

               63:  

               64:
              if (buildNumber
!= null && buildNumber.Contains("."))

               65: {

               66:
              string[]
buildNumberParts = buildNumber.Substring(buildNumber.LastIndexOf('_')+1).Split('.');

               67:  

               68:
              //
Dev_Versioning_20090305.4 -> 0903.02005
            

               69:
              //
use year (2 digits) and mont for buildversion
            

               70: buildVersion
= buildNumberParts[0].Substring(2, 4);

               71:  

               72:
              //
use day and number of build in this day for build revision
            

               73: buildRevision
= buildNumberParts[0].Substring(6) + buildNumberParts[1].PadLeft(3, '0');

               74: }

               75:
              return
              true;

               76: }

               77:
              #endregion
            

               78: }

               79: }

Das Property BuildNumber wird als Input-Parameter verwendet und mit dem Attribut [Required] versehen. Darüber kann die BuildNumber in unseren Task übergeben werden. Durch das Attribut [Output] werden die beiden Properties BuildVersion und BuildRevision als Rückgabewerte definiert. Beim Ausführen des Builds wird die Methode Execute aufgerufen. Hier werden nun aus der Build-Number die entsprechenden Informationen extrahiert und diese dann in BuildVersion und BuildRevision zurückgeschrieben. Dies ist natürlich nur ein einfaches Beispiel, aber mit diesen Grundlagen können nun beliebige Build-Tasks definiert werden. Im nächsten Schritt schauen wir uns an, wie wir diesen Custom Build Task nun in unseren Build-Prozess einbinden. Hierzu kopieren wir zunächst die Assembly in einen entsprechenden Ordner. Hier bietet sich an unter c:\Program Files\MSBuild einen entsprechenden Ordner anzulegen und dort die Assemblies abzulegen.

Nun muss das Build-Script entsprechend angepasst werden. Diese liegt in der Quellcode-Verwaltung und muss zum Bearbeiten zuerst aus- und danach wieder eingechecked werden. Um diesen Vorgang zu vereinfachen empfehle ich die TFS Sidekicks (http://www.attrice.info/downloads/index.htm) die direkt im Kontextmenü des TeamExplorers entsprechende Kommandos einfügt. Das nun ausgecheckte PROJ-File kann nun bearbeitet werden.

               1:
              <?
              xml
              version
              ="1.0"
              encoding
              ="utf-8"?>

               2:
              <!--
DO NOT EDIT the project element - the ToolsVersion specified here does not prevent
the solutions 
            

               3:
               and
projects in the SolutionToBuild item group from targeting other versions of the .NET
framework. 
            

               4:
               -->
            

               5:
              <
              Project
              DefaultTargets
              ="DesktopBuild"
              xmlns
              ="http://schemas.microsoft.com/developer/msbuild/2003"
              ToolsVersion
              ="3.5"
              >
            

               6:  

               7:
              <!--
Do not edit this -->
            

               8:
              <
              Import
              Project
              ="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets"
              />
            

               9:
              <
              Import
              Project
              ="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"
              />
            

               10:  

               11:
              <
              UsingTask
              AssemblyFile
              ="$(MSBuildExtensionsPath)\ArtisoBuildTasks\ArtisoBuildTasks.dll"
            

               12:
              TaskName
              ="ExtractRevision"
              />
            

               13:  

               14:
              <
              PropertyGroup
              >
            

               15:
              <!--
Assembly version properties. Adjust here Major and Minor Version-->
            

               16:
              <
              AssemblyMajorVersion
              >1</AssemblyMajorVersion>

               17:
              <
              AssemblyMinorVersion
              >3</AssemblyMinorVersion>

               18:
              <
              AssemblyBuildNumber
              >1</AssemblyBuildNumber>

               19:
              <
              AssemblyRevision
              >1</AssemblyRevision>

               20:
              </
              PropertyGroup
              >
            

               21:  

               1: ...

               2:
              <
              Target
              Name
              ="AfterGet"
              >
            

               3:
              <
              ItemGroup
              >
            

               4:
              <
              AssemblyInfoFiles
              Include
              ="$(SolutionRoot)\**\assemblyinfo.cs"
              />
            

               5:
              </
              ItemGroup
              >
            

               6:  

               7:
              <
              Message
              Text
              ="Get
Revision Number from BuildNumber &quot;$(BuildNumber)&quot;."
              />
            

               8:
              <
              ExtractRevision
              BuildNumber
              ="$(BuildNumber)"
              >
            

               9:
              <
              Output
              TaskParameter
              ="BuildRevision"
            

               10:
              PropertyName
              ="AssemblyRevision"
              />
            

               11:
              <
              Output
              TaskParameter
              ="BuildVersion"