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 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

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.

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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)

Referenzen

• Unit Tests (Wikipedia)
• Test-Driven Development (Wikipedia)

Literatur

• The art of unit testing, Roy Osherove
• Test-Driven Development in .NET, James W. Newkirk, Alexei A. Vorontsov
• Professional Software Testing with Visual Studio 2005 VS, Tom Arnold, Dominic Hopton, Andy Leonard, Mike Frost

In dieser Artikelserie möchte ich aufzeigen, was man benötigt um eine (meiner Meinung nach) professionelle Entwicklungsinfrastruktur aufzusetzen. Nun, wahrscheinlich hat jeder so seine eigenen Vorstellungen davon, was unter professionell zu verstehen ist. Gut möglich auch, dass einiges was der eine als professionell auffasst, der andere als unnötig oder übetrieben erachtet. Nichtsdestotrotz gibt es wohl den einen oder anderen Stützpfeiler in der Software-Entwicklung, der sich etabliert und eine gewisse Daseinsberechtigung erarbeitet hat.

Was ist also eine professionelle Entwicklungsinfrastruktur bzw. welche Ziele sollten bei der Einrichtung einer solchen verfolgt werden?

• Geht es einfach darum dem Entwickler Freude zu bereiten, ihm ein "gutes Gefühl" zu vermitteln?
• Dem Projektleiter und Kunden ein Gefühl von Sicherheit zu vermitteln?
• Oder einfach nur das Projekt rechtzeitig und gemäss Anforderungen abzuschliessen?

Richtig - idealerweise werden alle diese Punkte (und noch einige weitere) erreicht.
Eine gut funktionierende und unterstützende Infrastruktur ist zwar nicht die Garantie für all das, aber zumindest bietet sie einem das Werkzeug und die Hilfsmittel, diese Ziele zu erreichen.

Ich werde in diesem Artikel einen Überblick über die Komponenten aufzeigen, die aus meiner Sicht in eine Entwicklungsinfrastruktur gehören - also nicht "wäre noch nett"-Komponenten, sondern "ohne die mach ich keinen Fingerzeig"-Komponenten. Die nächsten Artikel werden dann jeweils detaillierter auf die einzelnen Komponenten eingehen. Die vorgestellten Tools habe ich dabei rein subjektiv ausgewählt. Wer bessere oder einfach andere Altnernativen bzw. Ergänzungen hat, ist angehalten diese per Kommentar mitzuteilen.

Die IDE

"An integrated development environment (IDE), also known as integrated design environment and integrated debugging environment, is a type of computer software that assists computer programmers in developing software." (Wikipedia)

Die IDE (=Integrated Development Environment) ist wohl das Tool, womit die meisten von uns am meisten Zeit verbringen. Und doch ist es für die Erreichung unserer Ziele wahrscheinlich das unkritischste von allen. Ob der Entwickler nun mit einer "echten" IDE wie VS 2005 oder einfach nur mit einem simplen Texteditor wie Notepad arbeitet, ist letztendlich seinen Angewohnheiten und Vorlieben überlassen. Für das Projektresultat ist die Wahl der IDE bzw. des Editors also insofern wichtig, dass der Entwickler mit seiner IDE quasi harmoniert und sie auch handhaben kann.

Vertreter dieser Kategorie: Visual Studio, SharpDevelop, Eclipse, IntelliJ, JBoss, etc.

In dieser Serie werde ich Visual Studio 2005 TS einsetzen.

Der Artikel zur IDE wird sich auf die Entwicklung von UnitTests mit VS 2005 beschränken.

Versionskontrolle

"Revision control (also known as version control (system) (VCS), source control or (source) code management (SCM)) is the management of multiple revisions of the same unit of information. It is most commonly used in engineering and software development to manage ongoing development of digital documents like application source code, art resources such as blueprints or electronic models and other critical information that may be worked on by a team of people." (Wikipedia)

Die SCC ist ein absolutes Muss für jeden der auch nur halbwegs professionell Software entwickelt. Erfreulicherweise ist der Einsatz eines entsprechenden Systems auch die Regel - aber leider bestätigen natürlich auch hier die Ausnahmen selbige. Eine gute SCC bietet neben des impliziten BackUps der lokalen Kopie, vorallem auch den Vorteil der Versionierung. Weiter sollte es möglich sein, Source Code auf verschiedenen Zweigen (= Branches) voranzutreiben bzw. Tags oder Labels vom Code zu erstellen. Was das genau ist und wie man damit umgeht, wird in Teil 3 dieser Serie besprochen.

SCC-Systeme werden meist mit Diff- und Merging-Tools ergänzt, da dies natürlich Funktionalitäten sind, die sich bei der täglichen Arbeit mit einer SCC notwendigerweise ergeben.

Die Wahl der SCC ist auch hier eher unbedeutend und sollte halt einfach die jeweiligen Bedürfnisse und Vorlieben abdecken.

Auch hier, einige Vertreter dieser Kategorie: CVS, Subversion, Visual SourceSafe, Sourcegear Vault

In der Serie wird Subversion eingesetzt.

Build-Script

Build automation is the act of scripting or automating the process of compiling computer source code into binary code. This automated build is in contrast to a manual build process where a person has to perform multiple, often tedious and error prone tasks. (Wikipedia)

Ein Build-Script ist keine eigentliche Software-Komponente, sondern halt nur ein Script. Was das Script dann schlussendlich tun soll, ist abhängig von den Wünschen und Anforderungen der Projektteilnehmer. Was es aber grundsätzlich natürlich immer kann bzw. können sollte, ist das schlichte kompilieren des Codes. Als erweiterte Möglichkeiten wären zum Beispiel folgende Punkte denkbar:

• Erstellung der Datenbank
• IIS Automatisierung (virt. Directories erstellen, Konfigurationen vornehmen etc.)
• Umgebungsabhängige Konfigurations-Dateien erstellen (Stichwort: ConnectionString)
• Automatisierte Test-Durchführung (z.B. UnitTests)
• SCC-Operationen
• und und und...

Seit .NET 2.0 haben .NET Entwickler die grosse Erleichterung, dass jedes Solution- bzw. Projektfile von Visual Studio 2005 selbst bereits ein MSBuild-Skript darstellt, welches zumindest mal die Solution oder das Projekt durch einen simplen Kommandozeilen-Aufruf von "msbuild mysolution.sln" kompilieren kann. Damit ist bereits die wichtigste Funktion eines BuildScripts abgedeckt, mit der auch schon einiges erreicht werden kann (z.B. automatische Kompilierung über Scheduled Tasks).

Vertreter dieser Kategorie sind zum Beispiel das eben genannte MSBuild, (n)ant oder auch die klassischen make-Files.

In dieser Serie werden wir auf MSBuild setzen.

Build-Server / Continuous Integration Server

"Continuous integration is the name that emerged in the Extreme Programming community for the software engineering practice of immediately committing every change, no matter how small, to a revision control system. Other developers should always work with the latest version of the codebase." (Wikipedia)

Build-Server im eigentlichen Sinne sind eigentlich heutzutage recht out.In aller Munde hingegen ist Continuous Integration oder kurz CI. Wo genau die Unterschiede sind, wird im entsprechenden Artikel behandelt - wobei der Schwerpunkt klar auf CI-Servern gelegt wird.

Vertreter dieser Kategorie sind Cruise Control (.NET), Team Foundation Server, TeamCity, Bamboo

Wir werden uns mit Cruise Control .NET beschäftigen.

Dies war mal so ein kleiner Überblick über die Themen dieser Serie. Jeder der folgenden Artikel wird dann ein einzelnes dieser Themengebiete genauer beleuchten.

Um nochmals auf die eingangs erwähnten Fragestellungen zurückzukommen:

• Geht es einfach darum dem Entwickler Freude zu bereiten, ihm ein "gutes Gefühl" zu vermitteln?
  Der Entwickler wird automatisch ein gutes Gefühl erhalten. Automatisch ausgeführte Builds, Tests etc. werden ihm stets das Gefühl verleihen, dass das Programm auf gutem Weg ist. Allein schon die morgendliche Nachricht, dass der Nightlybuild ohne Fehler durchgelaufen ist, wirkt hier Wunder. Im Artikel über CI werden wir aber noch einiges weiter gehen (Nightlybuilds != CI)
• Dem Projektleiter und Kunden ein Gefühl von Sicherheit zu vermitteln?
  Durch den Einsatz von CI können wir ein stets lauffähiges System vorweisen (das heisst nicht das alle Funktionen bereits vollständig implementiert sind etc.). Es gibt doch nichts Schlimmeres, als wenn der Kunde etwas sehen möchte und der Entwickler ihn mit lauter kryptischen (aber im Entwicklungsprozess) normalen Fehlermeldungen konfrontiert.
• Oder einfach nur das Projekt rechtzeitig und gemäss Anforderungen abzuschliessen?
  Hierfür brauchts natürlich noch einiges mehr, als eine gute Infrastruktur - aber ein erster Schritt ist damit getan.

Alle verwendeten Komponenten bis auf Visual Studio sind frei erhältlich, der Kostenpunkt sollte also zumindest was die Lizenzkosten anbelangt keinen Grund darstellen, auf diese wichtigen Komponenten zu verzichten - wie es mit dem Aufwand aussieht, werden die nächsten Artikel zeigen.

Ist zwar mittlerweile auch schon wieder ein paar Wochen her, aber es sei trotzdem erwähnt: Auch das zweite und letzte Vordiplom sitzt nun fest in meiner Tasche! Neben dem neu errungenen Zettel hat das vorallem auch die Konsequenz, dass das Grundstudium nun abgeschlossen ist, Adieu Mathe, Physik & Co. Dafür darf ich mich jetzt im ersten Semester des Fachstudiums mit folgendem befassen:

• Systemsoftware (Systemnahe Entwicklung mit C, insbesondere Multithreading-Applikationen mit Pthreads)
• Datenbanksysteme
• Data Mining
• Paralleles Rechnen

Vielleicht findet ja das eine oder andere Thema auch noch in dieses Blog.

Regionerate ist ein interessantes kleines Tool mit dem man C#-Code per Mausklick nach einem definierten Template umformatieren kann (zB. Fields, Properties, Methoden etc. in Regions trennen). So kann man sicherstellen, dass der Code immer gleich formatiert ist.

Dieser Screencast gibt einen guten Einblick in die Funktionen des Tools.

Das ganze funktioniert in VS 2005, Orcas und SharpDevelop. 

Scott Bellware, seines Zeichens (verdienter) C#-MVP, hat einen sehr interessanten Artikel über die Handhabung von Objekt-Referenzen geschrieben. Er geht kurz aber verständlich auf die möglichen Formen und deren Risiken ein, und zeigt wie man mit Hilfe eines Dependency Injection Frameworks wie Spring.NET seine Abhängigkeiten "lockern" kann und den Code somit testbarer zu machen. Sehr empfehlenswert!

Mit iTextSharp lassen sich einigermassen komfortabel mehrere PDF-Dateien in eine einzige mergen.

Folgendes Skript zeigt wies geht:

          using System; using System.IO; using iTextSharp.text; using iTextSharp.text.pdf; publicclassPdfMerge { publicstaticvoid MergeFiles(string destinationFile, string[]
sourceFiles) { try  { int f
= 0; PdfReader reader = new PdfReader(sourceFiles[f]); int n
= reader.NumberOfPages; Document document = new Document(reader.GetPageSizeWithRotation(1));
PdfWriter writer = PdfWriter.GetInstance(document, newFileStream(destinationFile, FileMode.Create));
document.Open(); PdfContentByte cb = writer.DirectContent; PdfImportedPage page; int rotation; while (f
< sourceFiles.Length) { int i = 0; while (i
< n) { i++; document.SetPageSize(reader.GetPageSizeWithRotation(i)); document.NewPage();
page = writer.GetImportedPage(reader, i); rotation = reader.GetPageRotation(i); if (rotation
== 90 || rotation == 270) cb.AddTemplate(page, 0, -1f, 1f, 0, 0, reader.GetPageSizeWithRotation(i).Height); else  cb.AddTemplate(page,
1f, 0, 0, 1f, 0, 0); } f++; if (f <
sourceFiles.Length) { reader = new PdfReader(sourceFiles[f]);
n = reader.NumberOfPages; } } document.Close(); } catch (Exception ex)
{ Console.Error.WriteLine(ex.Message);
} } }

Um Word-Dateien programmatisch in PDF's zu wandeln, gibts einige kommerzielle Lösungen. Eine günstigere, nämlich kostenlose Alternative bietet das Tool PDFCreator.

PDFCreator nistet sich als Druckertreiber in Windows ein und erlaubt so die PDF-Konvertierung verschiedenster Datentypen. Das beste daran: PDFCreator bietet in den neueren Versionen auch eine COM-Schnittstelle, womit das Tool auch elegant aus dem eigenen Code angesprochen werden kann.

Im Download von PDFCreator sind zwei Samples zur Nutzung des COM-Interfaces mit .NET (1.1 und 2.0) vorhanden. Sei noch zu erwähnen, dass es bei mir nur mit dem GPL-Download funktioniert hat.

Einziger Nachteil ist natürlich, dass für diesen Vorgang Word installiert sein muss.

Von meinem absoluten Liebling in Sachen "mach mehr aus VS" ist nun die Version 3 erschienen.

Neben dem, dass auch in der dritten Version meine zwei Cores mitsamt RAM arg gekitzelt werden, sind noch einige weitere nette Features dazugekommen.

Eine uneingeschränkte 30-tägige Testversion gibts hier.

Enums sind ein einfacher und komfortabler Weg um z. B. Status- oder Modus-Indikatoren zu speichern.
Jeder Entwickler braucht dieses Feature wohl tagtäglich, sei es über "built-in" Enumerationen wie System.IO.FileAccess oder über eigens definierte.

Basics

Hier als einfaches Beispiel ein Enum, das die Benutzungsart einer Software beschreibt:

            public
            enum
            UsageMode {
Private, Commercial, Education }

und deren Verwendung in einer Klasse "Software":

            public
            class
            Software { UsageMode usage
= UsageMode.Commercial; publicUsageMode Usage
{ get { return usage;
} set { usage = value;
} } }

Enums sind im Prinzip nichts anderes, als benannte Konstanten für Integer-Werte. Im Beispiel werden die Werte wie folgt implizit durchnummeriert.

            public
            enum
            UsageMode {
Private = 0, Commercial = 1, Education = 2 }

Dies lässt sich durch die schlichte Zuweisung eines beliebigen Integers aber ändern.

Dadurch, dass Enums neben benannten Konstanten eben auch numerische Werte darstellen, eignen sie sich auch sehr gut, um auf Arrays zu mappen.

            public
            class
            Software { UsageMode usage
= UsageMode.Commercial; string[]
humanText = newstring[]
{ "Private (non-commercial) usage", "Unlimited
commercial usage", "Educational usage"  }; publicUsageMode Usage
{ get { return usage;
} set { usage = value;
} } publicstring HumanText
{ get { return humanText[(int)usage];
} } }

Hier wird also eine Enumeration benutzt, um einen strukturierten Zugriff auf das String-Array humanText zu ermöglichen.

Wenns mal etwas mehr sein soll

Was nun aber, wenn ein Int32 für die gewünschten Datentypen nicht mehr ausreicht? Kein Problem, der zugrundeliegende Typ einer Enum kann über Vererbung geändert werden. So lässt sich eine Enum problemlos mit einem Int64 (long) verwenden:

            public
            enum
            UsageMode : long {
Private = 2147483640L, Commercial = 2147483641L, Education = 2147483642L }

Es liegt auf der Hand, dass dies nur in sehr speziellen Fällen notwendig ist - kann aber trotzdem sehr nützlich sein, wenn es zum Beispiel darum geht, Zahlen > 2^31 über benannnte Konstanten zugänglich zu machen.

Bit-Flags

Bis jetzt sind wir immer davon ausgegangen, dass sich die einzelnen Enumerationswerte ausschliessen. Nicht selten jedoch, sollen sich die Werte auch kombinieren lassen. So ist es durchaus vorstellbar, dass eine Software zu privaten wie auch kommerziellen Zwecken eingesetzt wird.

Dies lässt sich erreichen, indem man für die einzelne Werte auschliesslich Potenzen von 2 verwendet:

            public
            enum
            UsageMode {
Private = 1, // 2^0  Commercial = 2, //
2^1  Education = 4 // 2^2 }

Nun, wieso denn das? Wenn man sich dann die Verwendung anschaut, wird auch das klar:

usage = UsageMode.Commercial
| UsageMode.Private;

Die beiden Werte werden also mit einem | (OR) verbunden. Wenn man dies nun auf die Zahlenwerte überträgt

1 OR 2 = 3

sieht man, dass die Kombination einen Zahlenwert ergibt, die in der Enum nicht vorkommt und eindeutig diesem Paar zugewiesen werden kann.

Und das ist natürlich notwendig, da man ja den Wert der Enum auch abfragen will:

            bool isPrivateUsage
= (UsageMode.Private & usage) == UsageMode.Private;

Man ANDet also den aktuellen Wert (usage) mit dem zu prüfenden Wert (UsageMode.Private). Oder in Zahlen ausgedrückt:

1 AND 3 = 1

Nun liegt es natürlich nahe, dass man für die 3 hier auch einen Enum-Wert einführen könnte, zum Beispiel "PrivateAndCommercial", dies würde die Benützung vereinfachen, da zur Abfrage bzw. Aktivierung nicht jedes mal mit Bit-Operatoren hantiert werden müsste. Solche Kombinationen sollte man einführen, sofern sie gebräuchlich sind.

Oftmals wird auch ein Wert benötigt, der indiziert, dass keiner der Werte aktiviert wurde. Dieser (und nur dieser!) sollte dann jeweils mit der Zahl 0 versehen werden.

[System.Flags()] publicenumUsageMode {
None = 0, Private = 1, Commercial = 2, PrivateAndCommercial = 3, Education = 4 }

System.Flags-Attribut

Hier wurde nun noch das System.Flags-Attribut eingeführt. Dieses ist zwar nicht unbedingt notwendig für dieses Verhalten, ist jedoch empfehlenswert. Einfluss hat das Attribut zum Beispiel auf die Ausgabe des Enum-Wertes über die ToString()-Methode:

usage = UsageMode.Private
| UsageMode.Commercial; Console.WriteLine(usage.ToString()); 

// Ausgabe mit Flags: PrivateAndCommercial; Ausgabe
ohne Flags: PrivateAndCommercial usage = UsageMode.Private
| UsageMode.Education; Console.WriteLine(usage.ToString()); 

// Ausgabe mit Flags: Private, Commercial; Ausgabe
ohne Flags: 3

Die kombinierten Werte werden also bei gesetztem Flags-Attribut mit Kommata getrennt, statt einfach als Zahl, ausgegeben. Dies kann sehr nützlich sein. So kann man zum Beispiel über die Split-Funktion von String so die einzelnen Werte sehr einfach in ein Array überführen.

Fazit

Enums bieten also ein sehr einfaches und flexibles Werkzeug, um mit Konstanten Werten zu hantieren. Gerade Anfänger lassen sich zu gerne von der Flags-Funktion abschrecken, da sie so sehr nach "Bits rumschieben" schmeckt. Die Beispiele zeigen jedoch, dass die Anwendung denkbar einfach und dafür umso Leistungsfähiger ist.

Hier noch zwei interessante Links in diesem Zusammenhang:
Enum Design-Guidelines von Krzysztof Cwalina
MSDN (C#)