nettigkeiten.ch

Mehrspaltige DropDownList / ListBox

2008-10-02T20:49:0202:00:00

Eine doch lästige und unschöne Einschränkung bei der DropDownList ist doch, dass man nur ein Feld der DataSource an das Control binden kann.

Oft will man halt aber mehr als nur ein Feld darstellen:

Kategorie A: 3 Fahrzeuge

Kategorie B: 11 Fahrzeuge

Kategorie C: 1 Fahrzeug

Natürlich geht das relativ problemlos, z.B. mittels String-Concatenation, ist aber doch lästig, wenn man sonst alles schön über direktes DataBinding lösen könnte – zumal das Control ja auch einen FormatString zur Steuerung der Ausgabe entgegennimmt.

Eine Ableitung der DropDownList zu bauen, die das kann, ist zum Glück keine Kunst. Nachfolgend das Beispiel mit einer DropDown-List, die ListBox verhält sich analog.

Zuerst erstellt man sich also eine Klasse, die von DropDownList erbt:

        1: public class MultiColumnDropDownList : DropDownList
  

Die DropDownList nimmt den Namen des anzuzeigenden DataSource-Feldes im Property DataTextField auf. Ich benutze das Property gleich auch für meine Zwecke, lasse aber mehrere Angaben, getrennt durch ein Semikolon zu.

Die einzige Methode dies es dann zu überschreiben gilt ist PerformDataBinding. Dort kriegt man als Parameter die DataSource praktisch als IEnumerable.

       1: protected override void PerformDataBinding(System.Collections.IEnumerable dataSource)
  

Die eigentliche Implementation ist dann denkbar simpel:

       1: foreach (Object obj in dataSource)

       2: {

       3:     string[] textFieldsValues = new string[textFields.Length];

       4:     for (int i = 0; i < textFields.Length; i++)

       5:     {

       6:         textFieldsValues[i] = DataBinder.GetPropertyValue(obj, textFields[i].Trim()).ToString();

       7:     }

       8:  

       9:     ListItem li = new ListItem();

      10:     li.Text = string.Format(list.DataTextFormatString, textFieldsValues);

      11:     li.Value = DataBinder.GetPropertyValue(obj, list.DataValueField);

      12:     list.Items.Add(li);

      13: }

In Zeile 6 wird mittels der DataBinder-Klasse der Wert aus der DataSource gelesen. Hat den Vorteil, dass man sich nicht darum kümmern muss, was denn nun für eine DataSource dahinter steckt. Der Rest ist wohl selbsterklärend.

Eingebunden in einer aspx-Seite sieht dann das so aus:

       1: <NN:MultiColumnDropDownList  ID="ddlMulti" runat="server" 

       2:             DataSourceID="ObjectDataSource1" DataTextField="Name;PreName" 

       3:             DataValueField="Id" DataTextFormatString="{0} {1}" />

Und als Ausgabe:

Download der Sourcen

Herrlich! Göttlich!

2008-10-02T18:29:2802:00:00

Leider hört man ja von Maradona eigentlich selten noch erfreuliches, das soll aber nicht daran hindern, sich an alten Perlen zu erfreuen. Auf so eine bin ich heute im Schweizer Schundblatt Nr. 1 gestossen:

Da ist sogar das Einspielen ein Highlight!

Perfekte Einstimmung für heute Abend, wenn der FC Zürich, zwar kaum so brilliant, aber hoffentlich mit viel Kämpferherz die Milanesi rauskickt. :-)

Private Methoden mit UnitTests testen

2008-09-30T21:29:3402:00:00

Das Testen von privaten Methoden wirft immer wieder Fragen auf. Natürlich gibt es hierfür auch diverse Lösungen:

Visual Studio erstellt einen sogenannten Private Accessor, was schlussendlich nichts anderes als ein Wrapper ist, der mittels Reflection auf die privaten Members zugreift.
Das ganze ist mir eher unsympathisch und verkompliziert das ganze nur. Ausserdem entstehen Schwierigkeiten beim Mocking. Trotzdem war dies bis jetzt die Lösung meiner Wahl.
Private Members gar nicht testen. Da private Methoden in der Regel irgendwo mal aufgerufen werden, kann man diese über Tests von öffentlichen Methoden abhandeln. Mittels CodeCoverage lässt sich überwachen, dass die Methoden auch wirklich getestet werden. Nur wiederspricht das natürlich klar den Gesetzen von UnitTests.
Natürlich kann man sich auch etwas eigenes bauen, um mittels Reflection an die Methoden zu kommen.
Neben dem Aufwand birgt das natürlich auch Fehlerpotential – und Fehler in Tests sind eher doof :-)

Alles also irgendwie ok – aber halt doch nicht so. Heute bin ich aber über zwei Klassen gestossen, mit denen man das Problem doch recht einfach lösen kann: PrivateObject und PrivateType.

Und so siehts aus:

        1: string name = "Dani";

       2: string expected = "Hello Dani";

       3:  

       4: MyClass mc = new MyClass();

       5: PrivateObject po = new PrivateObject(mc);

       6: string actual = po.Invoke("SayHello", name).ToString();

Und für statische Methoden nimmt man einfach PrivateType:

       1: PrivateType pt = new PrivateType(typeof(MyClass));

       2: string actual = pt.InvokeStatic("SayBye", name).ToString();

nettigkeiten.ch goes Mobile!

2008-07-25T00:22:4202:00:00

Dank der MobileFeeds-Applikation meines früheren Arbeitgebers Connvision kann mein Blog nun auch komfortabel auf einem Mobile-Phone gelesen werden (mit entsprechend angepasster Darstellung).

Als Leckerli erhält man bei MobileFeeds auch gleich einen BeeTagg der auf den Mobile-Feed linkt. Die Software die man benötigt, um den BeeTagg zu lesen kriegt man hier oder auch über Wap-Push (weitere Infos: beetagg.com).

Ist der Reader erst installiert, kann man den untenstehenden BeeTagg lesen und wird auf den MobileFeed geleitet.

Hier noch eine kleine Demo wie kinderleicht das mit dem BeeTagg scannen so funktioniert:

Restaurant-Tip: Focacceria, St. Gallen (CH)

2008-07-22T21:22:2002:00:00

Ein kleines Novum hier im Blog. Ab und an will ich in Zukunft auf, meiner Meinung nach, besonders erwähnenswerte Restaurants hinweisen. Ich verstehe dies auch als kleine Belohnung für die jeweilige Crew, welche sich abgemüht hat, meiner Begleitung und mir einen schönen Abend zu ermöglichen. Schliesslich gibt es ja leider genug andere Beispiele.

Wer die Focacceria betritt, wird von einer warmen, etwas rustikalen und trotzdem modern angehauchten Atmosphäre empfangen. Im Erdgeschoss ist quasi der Imbiss-Bereich – wobei dies einen etwas negativen Touch hat, der hier wahrlich nicht angebracht ist.
Im hinteren Bereich erwartet einen dann eine Theke voller mediteraner Köstlichkeiten, welche einem direkt an einen italienischen Feinkosthändler erinnert. Da reihen sich feinste Antipasti neben selbstgemachten Pasten (z.B. Oliven) ein. Die Stars der Theke sind aber die x verschiedenen Käsesorten sowie de grosse Auswahl an verschiedenen Leckereien für den Fleischesser. Hier darf man nun also sein eigenes Focaccia zusammenstellen. Es gibt drei verschiedene Grössen, wobei zumindest ich für das Grösste schon einen rechten Hunger brauche. Dann kann man sich eine Fleisch- oder Käsesorte auswählen, zwei Antipasti sowie eine Paste. Salat (z.B. Ruccola) gibt’s gratis. Das Fleisch wird frisch angeschnitten und mit den anderen Zutaten in das erwärmte Focaccia gepackt. Nun noch ein prickelnd frisches Gazosa dazu, und die Ferien-Stimmung ist perfekt.

(Bild focacceria.ch)

Wer sich die schmale Treppe nach oben getraut, findet dort ein etwas eleganter aufgemachtes kleines Restaurant. Der obere Stock ist bedient. Man kann dort, neben den Focaccias auch von einer sehr kleinen aber feinen Karte aussuchen. Die Karte wird täglich geändert und offeriert einem gluschtige Tagliatelle, Suppen und Salate. Nach dem Essen sollte man sich unbedingt auf einen Dolci-Vorschlag der Bedienung einlassen, da gibt’s wirkliche Leckereien darunter.

Alles in allem ein wirklich gelungenes Lokal welches die totale Italianità versprüht. Die Preise sind zwar nicht ganz ohne, aber dafür erhält man auch wirklich qualitativ hervorragende Lebensmittel sehr gut zubereitet.

(Bilder focacceria.ch)

Die Focacceria befindet sich an der Metzgergasse 22, 9000 St. Gallen.

Alles neu!

2008-07-17T23:06:3202:00:00

Tattaaa! Happy New Year! Der erste Post 2008! Naja... ist ja erst Mitte Jahr

Die üblichen Entschuldigungen spar ich mir mal und konzentrier mich hier lieber auf die wichtigen Sachen. Ich habe mich, wie so manche andere auch in letzter Zeit, von dasBlog verabschiedet und mich für SubText entschieden.

Die Umstellung war recht harzig und mühsam und mit diversen Stolpersteinen versehen. Aber zum Glück gibts ja nette Leute die ihre Erfahrungen der Öffentlichkeit hinterlassen. Allen voran sei hier Oren Eini erwähnt, der sogar das UrlRewriting von SubText erweitert hat, so dass auch die meisten alten dasBlog-Links noch funktionieren sollten.

Solltet ihr trotzdem etwas nicht finden, dass noch nicht funktioniert, wär ich um eine kurze Meldung dankbar.

Auch wenn die alten Links dank Oren noch funktionieren sollten, passt eure Einstellungen doch trotzdem bitte auf die neue URL http://blog.nettigkeiten.ch an.

Schon komisch... da gibt's ein halbes Jahr lang kein Lebenszeichen, und kaum muss ich ins Militär, gibt's grad einen Relaunch... Naja, mal schauen, je nach Lage an der Front reichts dann vielleicht auch noch gleich für ein bisschen "anmalen".

Adventskalender bei entwickler-press.de

2007-12-01T14:22:1701:00:00

Heute schiessen ja die Adventskalender auf den verschiedensten WebSites geradezu aus dem Boden. Einer, dessen Besuch sich wirklich lohnt, ist auf entwickler-press.de zu finden. Dort gibts nämlich jeden Tag ein eBook gratis und franko zum Download, ja man muss sich noch nicht mal registrieren.

Heute gibts Managed Direct X und C#.

KeePass und Ubuntu

2007-12-01T14:09:5101:00:00

KeePass war mir unter Windows ein ständiger Begleiter und passte für mich perfekt zur Verwaltung meiner Passwörter. Mittlerweile ist meine Passwort-Datenbank auch schon recht angewachsen... blöd nur, dass es das Ding nur für Windows gibt.

Trotzdem - mal googlen... aah...

KeePassX, eine Portierung von KeePass für Linux- und Mac-Systeme - und ja, es kann die KeePass-Datenbanken lesen - und auch umgekehrt. So kann ich also weiterhin die bestehende Datenbank nutzen und diese unter Linux mit KeePassX und unter Windows mit KeePass lesen.

KeePass
KeePassX

Ich geh fremd!

2007-11-28T20:34:3301:00:00

Nachdem ich schon seit längerem ein Doppelleben führte, habe ich mich nun definitiv entschieden! Seit der Version 7.10 bin ich vollständig auf Ubuntu umgestiegen. Wieso denn das?

Durch mein Studium musste ich mich zwangsweise das eine oder andere Mal mit Linux auseinandersetzen, und je länger ich damit arbeitete, desto mehr stieg meine Begeisterung dafür. Die Arbeit damit ist einfach effizienter, die typischen Slow-Downs die ich unter Windows immer wieder hatte (Vista kann man fast als andauernden Slow-Down bezeichnen ;-) ) bleiben unter Linux eine wirkliche Seltenheit.

Dazu kommt noch, dass es eine ganze Menge an kleinen feinen Tools gibt, die natürlich allesamt Open-Source sind.

Natürlich komme ich, als .NET-Entwickler, nicht um Windows rum - aber dafür gibts ja VMWare.

Eine professionelle Entwicklungsinfrastruktur für (fast) lau (Teil 2 von 5) - IDE

2007-11-28T19:33:5301:00:00

Mit knapp 2 Monaten Verspätung folgt nun also der zweite Teil dieser kleinen Serie :-)

Die IDE ist das meist täglich gebrauchte Werkzeug eines jeden Entwicklers. Unter .NET ist das mit Abstand am meisten verbreitete Exemplar dieser Gattung Visual Studio in den verschiedenen Ausprägungen. Wie bereits in Teil 1 geschrieben, erachte ich die Wahl der IDE als sekundär, Hauptsache der Entwickler findet sich damit zu Recht - also vergleichbar mit den Kochmessern eines Küchenchefs :-)

Dieser Artikel wird zeigen, wie man mittels Visual Studio 2008 seine Projekte mit UnitTests testet. UnitTests sollten genauso ein Selbstverständnis für einen Entwickler sein, wie auch alle anderen Punkte dieser Serie. Ich möchte hier nicht ins Detail gehen, das machen andere schon sehr gut - trotzdem aber die wichtigsten Punkte, um was es beim Unit-Testing geht. Zuerst also etwas Theorie.

Definition

Für ne schlaue Definition muss wiedermal Wikipedia herhalten:

"(...) unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application."

Also - man testet den kleinst-möglichen testbaren Teil einer Applikation - und das ist per Definition in einer OO-Anwendung natürlich die Methode. Dieser scheinbar unspektakuläre Satz, beeinhaltet schon einige der Grundsätze von Unit Tests.

Jeder Unit-Test testet genau eine Methode, nicht mehr und nicht weniger. Es werden also keine ganzen Abläufe (z.B. Abfolge von Method-Calls) getestet.
Das Resultat eines Unit-Tests sagt aus, ob die Methode (und nur genau die) gemäss dem definierten Testfall korrekt funktioniert.

Unit-Tests sollten immer möglichst einfach gehalten werden, dies reduziert das Risiko von Fehler im Test selbst.

Test-Driven Development

Im Zusammenhang mit Unit-Tests wird oftmals von Test-Driven Development (TDD) gesprochen. Wie der Name schon sagt, geht es dabei darum, mittels Tests zur eigentlichen Implementation zu kommen. Neue Funktionen werden stets gegen die zuvor definierten Testfälle implementiert und getestet. Eine Funktion gilt dann als implementiert, wenn diese alle für sie definierten Testfälle erfolgreich durchlaufen kann. In diesem Zusammenhang ebenfalls wichtige Konzepte sind

KISS - Keep it simple, stupid
YAGNI - You ain't gonna need it

Wichtiger Punkt im TDD ist also, nur genau das zu implementieren, was auch gefordert wird - und alles was gefordert wird, muss als Testfall hinterlegt sein. Jede Funktion die zusätzlich implementiert wird, quasi als gutgemeinten Bonus, ist nicht getestet (zumindest durch Unit-Tests) und stellt daher eine Verletzung dieser Prinzipien dar.

Die Regeln des Test-Driven Development

Der Ablauf beim TDD erscheint vielen Entwicklern anfangs etwas umständlich und gewöhnungsbedürftig. Auch scheinen die Regeln teils etwas überbestimmt. Trotzdem hat jede dieser Regeln ihre Berechtigung.

Schreibe den Test
Hier werden viele bereits stutzig. Den Test vor der eigentlichen Methode schreiben? Genau! Denn die Methode soll ja vom Test abhängen und nicht umgekehrt. Andersrum besteht immer die Gefahr, dass der Test um die Methode gebaut wird. Man testet das, was man weiss das die Methode kann - und nicht was sie können sollte.
Implementiere die Methode so, dass sie (und der zuvor definierte Test) gerade mal kompiliert, der Test aber fehlschlägt
Dieser Punkt wird oft ignoriert, da er so trivial erscheint. Der Punkt, dass der Test aber immer zuerst fehlschlagen soll, ist sehr zentral, da auch ein Test - wie jedes andere Stück Software auch - prinzipiell Fehler enthalten kann. Das heisst, der Test könnte immer erfolgreich sein, obwohl der Case gar nicht erfüllt ist. Dieser Punkt ist also quasi der Test des Tests.
Implementiere die Methode so, dass sie den Testfall besteht
Nun gehts also ans Eingemachte, die Methode soll ihre Implementation erhalten, und zwar so, dass sie den zuvor geschriebenen Test erfolgreich durchläuft. Wichtig dabei ist, dass hier noch nicht die ultimative Super-Lösung gebaut werden soll. Es soll in erster Linie mal einfach funktionieren. Nachdem in Punkt 2 ja getestet wurde, dass der Test fehlschlägt wenn er soll, muss jetzt ja auch mal gezeigt werden, dass er zu einer funktionierenden Methode auch sein "OK" gibt.
Refactor
Nun wird die laufende Lösung von Punkt 4 mittels Refactoring "verschönert". Der Test muss danach natürlich immer noch korrekt durchlaufen werden.
Starte wieder bei Punkt 1
Eine Methode hat in den seltensten Fällen nur einen Testfall. Da die Fälle sehr einfach gehalten werden sollen, gibt es hier meist ein ganzes Set von Tests pro Funktion. Dieser Punkt streicht den iterativen Ansatz dieser Methodik hervor. Die Implementation wächst also iterativ mit jedem Testfall, und ist genau dann fertig, wenn keine weiteren Fälle mehr zu definieren sind und alle definierten Fälle erfolgreich abgeschlossen werden können.

Wieso denn nun das ganze? Die Vorteile die aus dieser Vorgehensweise entstehen sollten für sich sprechen:

Fehlerfreie Software?
Nicht ganz - aber man weiss zumindest, und kann auch jederzeit nachprüfen, dass eine Funktion mit den definierten Testfällen klar kommt. Natürlich heisst das noch lange nicht, dass damit die Software korrekt funktioniert oder gar fehlerfrei ist. Jedoch kann man von einem gewissen Grad an Korrektheit ausgehen. Sollten trotzdem Fehler auftreten, waren die Testfälle nicht ausreichend.
Entspannte Änderungen
Jeder kennt das, man muss an einer Software etwas ändern und man ist sich vielleicht nicht ganz 100%ig über die Konsequenzen im Klaren. Side-Effects treten ja meist an den Stellen auf, an denen man sie am wenigsten vermutet. Kann der Entwickler jedoch nach seiner Änderung auf eine Fülle von erfolgreich abgearbeiteten Testfälle blicken, wird das sein Vertrauen merklich steigern. Auch hier gilt aber natürlich Vorsicht, die Änderung kann trotzdem Fehler verursachen! Evtl. müssen für die Änderung auch neue Tests eingeführt werden.
Dokumentation
Auch diese Situation ist wohl den meisten bekannt - man hat eine Methode vor sich und kann irgendwie nicht so greifen, was diese überhaupt genau macht. Die "erklärenden" Sätze in den Kommentaren machen das ganze auch nicht einfacher. Die Testfälle hingegen zeigen mit sehr übersichtlichem und einfachem Code, was die Methode zu erfüllen hat.
Lose Kopplung
Dies kommt praktisch gratis mit TDD mit. Denn wer so vorgeht, wird automatisch wenig Abhängigkeiten erzeugen. Abhängigkeiten sind immer irgendwo problematisch beim testen - da wird man sich also hüten.

Die Krux mit den Abhängigkeiten

Wie bereits geschrieben, sind Abhängigkeiten ein grundsätzliches Problem beim Unit-Testing. Man stelle sich zum Beispiel vor, man möchte eine Methode einer Datenbankzugriffsklasse testen. Beim schlichten Aufruf dieser Methode wird automatisch auch die Datenbank aufgerufen. Was test man so nun? Funktioniert das Db-Statement? Ist die Datenbank erreichbar? Oder doch nur ob die Funktion korrekt funktioniert? Ja genau - alles zusammen, und doch wieder nichts. Wenn was schief geht, ist nicht klar warum. Daraus ergeben sich einige Grundregeln, die man beim Schreiben der Tests beachten sollte:

Ein Unit-Test sollte nie

I/O-Funktionalität aufrufen (Filesysteme, Datenbanken, Netzwerk... alles tabu)
auf ein Konfigurations-File angewiesen sein
von anderen Unit-Tests abhängig sein. Jeder Test muss für sich allein funktionieren.

Solche Abhängigkeiten werden mit Hilfe von Mock-Objekten nachgebaut. Hierzu wird nächstens ein eigener kleiner Artikel folgen.

Wer all dies berücksichtigt - wird glücklich mit TDD - da leg ich meine Hand ins Feuer :-)

TDD mit Visual Studio 2008

Das neue Visual Studio (wie auch das alte :-) ) bietet alles, was man zu TDD benötigt. Zur Veranschaulichung ziehen wir mal so ein Szenario durch. Als Beispiel dient uns eine Applikation, die beliebige Zeichenketten durch verschiedene Sortieralgorithmen sortieren kann - so zum Beispiel mit QuickSort, ein beliebter "Divide and Conquer"-Algorithmus.

Als Ausgangslage dient uns folgender Aufbau der Applikation:

Program.cs beinhaltet etwas Code zur Verarbeitung der Eingabe sowie die schlussendliche Ausgabe des Resultates. ISortAlgorithm ist ein Interface, welches die Schnittstellen eines Sortieralgorithmus' vorgibt - nämlich:

public interface ISortAlgorithm
{
  string Sort(string toSort);
}

Nun haben wir ja vorhin einen schönen Ablauf definiert, also sehen wir mal ob der was taugt:

Punkt 1 - Test schreiben:

An dieser Stelle erlaube ich mir bereits die erste kleine Abweichung obiger Regel. Und zwar erstelle ich mir jeweils aus Bequemlichkeit bereits die Klasse sowie den Methodenrumpf bevor ich den Test schreibe. Das hat den Vorteil, das man beim Test schreiben auf IntelliSense zurückgreifen kann und nicht alles komisch rot unterstrichen erscheint. Ausserdem kann man sich das Gerüst für die Tests gleich in Visual Studio generieren lassen.

Ich erstelle also die Klasse QuickSortAlgorithm und implementiere das obige Interface ISortingAlgorithm. Das ist's dann aber auch schon. Danach genügt ein Rechtsklick ins Fenster zum Erstellen des Test-Projektes.

In dem generierten File findet sich dann eine Methode SortTest. Dies ist nun also unser Test, dessen Logik wir nun noch zu definieren haben.

       [TestMethod()]
       public void SortTest()
       {
            QuickSortAlgorithm target = new QuickSortAlgorithm(); // TODO: Initialize to an appropriate value
            string toSort = string.Empty; // TODO: Initialize to an appropriate value
            string expected = string.Empty; // TODO: Initialize to an appropriate value
            string actual;
            actual = target.Sort(toSort);
            Assert.AreEqual(expected, actual);
            Assert.Inconclusive("Verify the correctness of this test method.");
        }

Das TestMethod-Attribut gibt an, dass es sich bei der Methode um einen Test handelt. Dies ist notwendig, damit Visual Studio damit zu Recht kommt.

Um dies zu tun, muss man sich natürlich über die Anforderungen im Klaren sein. Unit-Tests sind WhiteBox-Tests - der Entwickler weiss also von der Implementation, dies ist auch nötig, wie wir später noch sehen werden. Also die Anforderung ist, dass wir der Methode einen String übergeben können und dieser sortiert zurück kommt. Entsprechend passen wir den Test an:

        [TestMethod()]
        public void SortTest()
        {
            QuickSortAlgorithm target = new QuickSortAlgorithm();
            string toSort = "bda";
            string expected = "abd";
            string actual;
            actual = target.Sort(toSort);
            Assert.AreEqual(expected, actual);
        }

Sehr schlicht und einfach also das ganze. Gut - und nun zu Punkt 2.

Punkt 2 - Methode implementieren, dass der Test fehlschlägt

Einfach, aber wichtig - also, wir geben einen Wert zurück, der den Test dazu veranlassen müsste, fehlzuschlagen - also zum Beispiel einen Leerstring.

Nun lassen wir den Test ein erstes Mal laufen um zu schauen, ob das Erwartete auch wirklich eintrifft. Ein Weg den Test zu starten ist wiederum über das Kontextmenü der Testmethode:

Und erhält folgendes Resultat:

Wenn das Resultat hier auf "Passed" wäre, wüsste man nun, dass der Test noch fehlerhaft ist, da er offensichtlich falsche Daten also korrekt klassifizierte.

Auf die restlichen Punkte muss hier nicht genauer eingegangen werden. Nun geht es einfach noch darum, die Implementation korrekt zu machen, und weitere Testfälle zu definieren, die sicherstellen, dass der Algorithmus korrekt funktioniert.

Weitere Testfälle wären zum Beispiel:

weitere Strings die korrekt sortiert werden müssen (spezielle Daten!), erwartet korrekt sortierte Rückgaben
ein Leerstring als Übergabe, erwartet einen Leerstring als Rückgabe
null als Übergabe, erwartet eine NullReferenceException
usw.

Das Beispiel mit einigen definierten Testfällen gibt's zum Download.

Code Coverage

Die Code Coverage gibt an, wieviel Prozent der Code-Statements durch einen Test abgedeckt werden. Dieser Wert sagt zwar prinzipiell nicht sehr viel aus, man sollte die Coverage aber dennoch immer etwas im Auge behalten. Ziel sollte ein Wert jenseits der 90%-Marke sein.

Mit Visual Studio lässt sich die Code Coverage sehr einfach messen. Hierzu müssen aber zuerst die Assemblies ausgewählt werden, auf denen die Messung stattfinden soll. Das entsprechende Menu findet man hier:

Danach kann man, nachdem die Tests durchgeführt wurden, das Code Coverage-Fenster öffnen und sich die Resultate zu Gemüte führen.

In dem Fenster kann man sich dann auch gleich anzeigen lassen, welche Zeilen durch einen Test abgedeckt werden und welche nicht. So kann man seine Testfälle optimieren.

Dies zeigt nun auch, wieso Unit-Tests eben WhiteBox-Tests sein müssen. Damit die Testfälle alle Verzweigungen einer Methode berücksichtigen kann, muss der Entwickler des Testfalls wissen, wie die Methode implementiert ist.

Natürlich sagt eine CodeCoverage von 100% nicht sonderlich viel aus - es ist weder ein Qualitätsmerkmal für den Code noch für die Testfälle. Es geht dabei mehr darum, zu entdecken, ob gewisse Code-Teile nicht getestet werden.

Fazit

Unit Tests und TDD sind ein grosses und wichtiges Thema. Visual Studio ermöglicht einen komfortablen Einsatz. Seit der 2008-Version, weden Unit-Tests bereits in der Professional-Variante unterstützt. Allerdings geht es auch ohne - Tools hierfür gibt es wie Sand am Meer. Erwähnt seien hier NUnit, NCover und TestDriven.Net (kostenpflichtig).

Viel braucht es also nicht, um Test-Driven entwickeln zu können. Trotzdem stellt sich der Anfang als eher harzig heraus, da es doch eine etwas andere Denk- und Vorgehensweise erfordert. Die Vorteile überwiegen aber doch klar, und wer sich einmal daran gewöhnt hat, wird es nicht mehr missen wollen.

Und hier noch das Beispiel-Programm zum Download:
StringSort.zip (57.99 KB)