„Entwickler sind die schlechtesten Tester“

Diese Aussage habe ich noch vor einigen Jahren öfter benutzt. Die Argumentation war, dass Entwickler ja die zu entwickelnde Applikation kennen und deshalb immer nur das testen, was auch funktioniert. Wer mich kennt weiß, dass ich heute eine ganz gegenteilige Meinung habe. Aber warum? Testen ist ein elementarer Teil der Softwareentwicklung. So wie es niemandem einfallen würde einen nicht kompilierten C# Code an einen Kunden auszuliefern würde auch niemand eine ungetestet Software ausliefern. Jeder Entwickler testet deshalb auch den ganzen Tag. Alle paar Minuten (oder spätestens nach ein paar Stunden) wird wieder die neue Funktionalität getestet. Nur leider machen die … Continue reading „Entwickler sind die schlechtesten Tester“

MCSD is back

Offensichtlich verabschiedet sich Microsoft wieder von der Trennung MCTS und MCPD und wir bekommen wieder unserer alten guten MCSD zurück. Folgende MCSD Varianten gibt es gerade: MCSD: Application Lifecycle Management MCSD: Web Applications MCSD: Windows Store Apps Außerdem gibt es den kleinen Bruder MTA (Microsoft Technology Associate): MTA development track—for those intending to build a career as a software developer, this track helps prepare you for hands-on product training and MCSD certification. Start with MTA Software Development Fundamentals and then select the additional topics in this track to help you meet your career development goals: Exam 98-361: Software Development Fundamentals … Continue reading MCSD is back

InternalsVisibleTo-Attribut

Das InternalsVisibleTo Attribut erlaubt es interne Methoden in anderen Bibliotheken zu verwenden. Besonders für das Testen ist das sehr wichtig – aber es hilft auch die größten Teile der Anwendung geschlossen zu halten und das extern sichtbare Interface so klein wie möglich zu halten. Bei signierten Projekten muss man den Publik-Key wie folgt angeben: Den PublicKey erhält man über sn.exe mit der Option -Tp: Continue reading InternalsVisibleTo-Attribut

Argument Validation

Es ist gute Praxis alle Argumente zu validieren, bevor sie verwendet werden. Würde in diesem Beispiel das Argument nicht geprüft, dann würde eine DivideByZeroException geworfen werden (was zugegebenermaßen in diesem Beispiel auch nicht ganz sinn frei wäre – aber ich denke der Gedanke dahinter ist klar). Besonders bei Referenztypen ist es kritisch, da diese NULL sein können. Wird die Validierung vergessen, dann wird eine NullReferenceException geworfen. Deshalb gibt es in der Codeanalyse auch die Regel CA1062: Validate arguments of public methods. Würde eine Methode so aussehen: Würde man eine NullReferenceException bekommen, wenn das Objekt NULL wäre. Außerdem muss man aufpassen, … Continue reading Argument Validation

Error Handling Part 3: Guidelines nach David Abrahams

Dies ist der dritte Teil der Serie zum Thema Exception Handling: Grundlagen der Fehlerbehandlung Eigene Ausnahamen werfen Guidelines nach David Abrahams Fehlerbehandlung auf Anwendungsebene David Abrahams hat 3 Guidelines definiert, an die sich Entwickler von Klassenbibliotheken halten sollen: Die no-throw guarantee Die basic guarantee Die strong guarantee Es geht dabei um 3 Arten von Verträgen, die man als Autor einer Klasse den Konsumenten verspricht. No-Throw Guarantee Bei der “no-throw guarantee” muss sichergestellt werden, dass keine Exception die Kasse/Funktion verlässt. Dies bedeutet natürlich, dass beim Auftreten eines Fehlers in einer untergeordneten Komponente folgendes sichergestellt werden muss: Keine Exception verlässt die Funktion: … Continue reading Error Handling Part 3: Guidelines nach David Abrahams

Keine Angst vor dem Mergen…

Immer wieder sehe ich, dass Entwickler Probleme mit dem Mergen von Code im Repository haben. Das Mergen ist aber kein mystischer Vorgang, bei dem uns der TFS unseren Code zerstört. Das Mergen ist einfach nur das Zusammenführen von Änderungen mehrerer Personen an denselben Dateien. Wenn z.B. zwei Entwickler einer Klasse je eine Funktion hinzufügen, dann meldet der TFS einen Konflikt. Die Funktionen “Keep Local Version” und “Take Server Version” dienen nur zum Zurücksetzen und spielen hier keine Rolle. Ein Klick auf “Merge Changes In Merge Tool” öffnet das Mergetool. In den oberen beiden Fenstern sieht man die Änderungen: lokal (Yours) … Continue reading Keine Angst vor dem Mergen…

Error Handling Part 1: Grundlagen bei der Fehlerbehandlung

In letzter Zeit wurde ich immer wieder gebeten etwas über Fehlerbehandlung zu schreiben. Da das Thema komplex und sehr umfangreich ist habe ich mich immer wieder darum gedrückt. Man sieht aber in der Praxis leider doch, dass es immer wieder Probleme damit gibt. Deshalb habe ich mich jetzt endlich aufgerafft das Thema anzugehen. Da das Thema zu Komplex für einen einzelnen Beitrag ist, werde ich das Ganze als Serie aufbauen: Grundlagen der Fehlerbehandlung Eigene Ausnahamen werfen Guidelines nach David Abrahams Fehlerbehandlung auf Anwendungsebene Beim Verwenden einer Try-Catch-Anweisung kann man wirklich viel falsch machen. Viel mehr als einem meistens bewusst ist. … Continue reading Error Handling Part 1: Grundlagen bei der Fehlerbehandlung

Error Handling Part 2: Eigene Ausnahmen werfen

Hier ist der zweite Parte der Serie über Fehlerbehandlung: Grundlagen der Fehlerbehandlung Eigene Ausnahamen werfen Guidelines nach David Abrahams Fehlerbehandlung auf Anwendungsebene Diesmal geht es darum wann und wie Ausnahmen generiert werden sollen. Generell gilt: Ausnahmen sollten immer dann geworfen werden, wenn die Anwendung oder das Objekt sonst in einen undefinierten Zustand gerät. Ausnahmen sollen kein Teil des normalen Programmflusses sein. Ein gutes Beispiel wie es NICHT geht liefert uns mal wieder SharePoint: Wenn ich auf ein Objekt in eine Auflistung zugreifen will, das nicht existiert werde ich mit einer ArgumentException oder eine SPException überrascht. Dies führt zu folgenden Funktionen, … Continue reading Error Handling Part 2: Eigene Ausnahmen werfen

System.Object.ToString()

Die ToString() Methode ist eine der am meisten verwendeten Funktionen im .Net Framework. Sie ist die einzige Methode die von System.Object implementiert wird und deshalb bei jedem Objekt verfügbar ist – ganz egal von welchem Typ. Die ToString()-Methode erlaubt die Repräsentation eines Objektes als String. Wird sie nicht angegeben, muss jeder Benutzer der Klasse immer selber entscheiden (und entwickeln), wie die Klasse dargestellt wird. Besonders beim Databinding ist das ein immer wiederkehrender Task. Es sollte also immer ein sinnvoller “override” gemacht werden, der eine sinnvolle Darstellung des Objektes als string zurück-gibt. Im einfachsten Fall sieht die Implementierung einfach so aus: … Continue reading System.Object.ToString()