Testing ist möglich, ohne die Code-Basis zu lähmen. Ziel dabei sollte immer sein, die Lesbarkeit, Wartbarkeit und Auffindbarkeit von Unit-Tests zu verbessern. Dennis Doomen gibt auf der DDC - .NET Developer Conference zwölf Tipps für bessere Unit Tests.  Testen sichert die Qualität von Software, ist jedoch bei Softwareentwicklern nicht so sehr beliebt. Oft wird behauptet, dass deren Zeit zu kostbar sei, um sie für Testing zu "verschwenden". Jedoch ist es ein Fakt, dass etwa mit Test Driven Development (TDD) von Anfang an die Qualität hoch gehalten wird und somit erst gar nicht so schlimme Fehler passieren, damit gewinnen Entwickler ein Sicherheitsnetz im alltäglichen Schaffen hinzu. Neben der erleichterten Wartbarkeit werden neue Features daher öfter implementiert. TDD besteht aus zwei Elementen: Unit-Testing und Integrationstests, die das Zusammenspiel der einzelnen Komponenten einer Software überprüfen. Unit-Tests beziehen sich auf die Komponenten eines Systems selbst – Methoden, Klassen, Subsystem, Gesamtsystem. Deren Charakteristika und gleichzeitig Vorteile sind, dass Unit-Tests automatisiert wiederholt werden können, unabhängig sind und einfach sowie effizient zu implementieren sind. Als Tool für den Entwickleralltag sind Unit-Tests unbedingt zu empfehlen, denn einmal erleichtert es die Tätigkeit an sich oder macht sie angenehmer und zusätzlich wird die Softwarequalität gesichert und stetig gesteigert, indem auch das Requirements Engineering unterstützt wird und der Kunde am Ende zufriedener ist. Es darf aber nicht vergessen werden, dass Unit-Testing nur die Wasserwaage ist – ohne weiteres Werkzeug lässt sich damit nur schwer ein grundsolides Haus bauen. Vorab verrät Dennis drei Tipps für eine Steigerung der Softwarequalität:

1. Bibliothek mit Bedacht verwenden: AutoFixture [1] ist eine Open Source-Bibliothek für .NET, die für eine optimale Wartbarkeit die Vorbereitung-Sektion (= Arrange), die erste der drei Phasen Arrange, Act, Assert, minimiert. Nützliche Libraries wie diese sollten nur mit Bedacht verwendet werden, denn sie beeinträchtigen die Performance. Dazu erhöhen sie sogar die Wahrscheinlichkeit, dass der Test einen Fehler ausgibt (= Red), obwohl dieser für den speziellen Testfall nicht relevant ist.
2. Style dem Testfall anpassen: Selbst auferlegte Beschränkungen auf einen einzigen Style kritisch zu überdenken, ist von Zeit zu Zeit sinnvoll. Auch wenn es nicht empfehlenswert ist, innerhalb einer Code-Basis oder eines Repositorys eine Vielzahl von Styles anzuwenden, ist es doch empfehlenswert, die Syntax dem Zweck anzupassen. Dennis Doomen empfiehlt z. B. für Status-Tests die AAA Syntax (Arrange-Act-Assert), verwendet jedoch für Orchestrierungs-Tests Behavior Driven Development.
3. Keine Konstanten am Anfang: Außer wenn eine magische Zahl zum Einsatz kommt, hat eine konstante Variable am Anfang eines Tests nichts zu suchen. Stattdessen sollten Literals wie "TheIdentifier" oder "OtherIdentifier" verwendet werden. Sogar numerische Werte wie 1123 benötigen keine Konstanten, auch wenn sie mehrfach eingesetzt werden.