Ermitteln, welche Klassen am besten von Komponententests profitieren würden?

Question

Ich arbeite an einem Projekt, bei dem wir nur 13% der Codeabdeckung mit unseren Unit-Tests haben. Ich würde gerne einen Plan entwickeln, um dies zu verbessern, indem ich mich zunächst auf die Bereiche konzentriere, in denen eine zunehmende Abdeckung den größten Nutzen bringen würde. Dieses Projekt ist in C#, wir verwenden VS 2008 und TFS 2008 und aus Unit-Tests werden mit MSTest geschrieben.

Welche Methode sollte ich verwenden, um zu bestimmen, welche Klassen wir zuerst angehen sollten? Welche Metriken (Code oder Verwendung) sollte ich untersuchen (und wie kann ich diese Metriken bekommen, wenn das nicht offensichtlich ist)?

Answer 1

Für einige gute Statistiken und deterministische Abfrage von bestimmten Methoden dienen Sie auf jeden Fall auf NDepend aussehen könnte: http://www.ndepend.com/

NDepend stellt eine Abfragesprache CQL (Code Query Language) genannt, mit dem Sie Abfragen in Bezug auf Ihren Code in Bezug auf bestimmte Statistiken und statische Analysen schreiben können.

Es gibt keinen wirklichen Weg, um zu bestimmen, welche Klassen am meisten profitieren könnten. Wenn Sie jedoch eigene Schwellenwerte in CQL setzen, können Sie einige Regeln und Konventionen festlegen.

Answer 2

Ich würde empfehlen, Komponententests zu allen Klassen hinzuzufügen, die Sie berühren, und keine vorhandenen Klassen nachzurüsten. Die meisten Vorteile von Komponententests liegen darin, Programmierern beim Codieren zu helfen und zu gewährleisten, dass "Fixes" nichts kaputt machen, wenn Sie einem neuen Codeabschnitt, der nicht alle Modifizierungen enthält, keinen Code hinzufügen von Komponententests beginnen abzufallen.

Sie könnten auch Einheitentests zu Klassen hinzufügen, auf die Sie angewiesen sind, wenn Sie nichts Besseres zu tun haben.

Sie sollten Tests zu neuen Funktionen, die Sie hinzufügen, unbedingt hinzufügen, aber Sie sollten wahrscheinlich auch Tests zu vorhandenen Funktionen hinzufügen, die Sie möglicherweise unterbrechen.

Wenn Sie einen großen Refactor erstellen, sollten Sie zunächst eine Abdeckung von 80-100% für diesen Bereich in Erwägung ziehen.

Answer 3

Der größte Wert eines Komponententests ist die Wartung, um sicherzustellen, dass der Code auch nach Änderungen weiterhin funktioniert.

Konzentrieren Sie sich also auf Methoden/Klassen, die höchstwahrscheinlich/am häufigsten geändert werden.

Als nächstes sind Klassen/Methoden mit weniger als offensichtliche Logik wichtig. Die Unit-Tests werden sie weniger zerbrechlich, während als extra „Dokumentation“ für ihre kontrahierten API

Answer 4

Ordnen Sie alle Ihre Komponenten in Ebenen. Jede Klasse in einem bestimmten Level sollte nur von Komponenten auf einer niedrigeren Ebene abhängen. (Eine "Komponente" ist eine beliebige logische Gruppe aus einer oder mehreren Klassen.)

Schreiben Sie zuerst Gerätetests für alle Komponenten der Ebene 1. In der Regel müssen Sie keine Frameworks oder einen anderen ähnlichen Unsinn verspotten, da diese Komponenten nur auf .NET Framework basieren.

Sobald Level 1 fertig ist, beginne auf Level 2. Wenn Level 1 Tests gut sind, brauchst du diese Klassen nicht zu verspotten, wenn du deine Level 2 Tests schreibst.

Fahren Sie in gleicher Weise fort und arbeiten Sie den Anwendungsstapel hoch.

Tipp: Zerlegen Sie alle Ihre Komponenten in levelspezifische DLLs.Auf diese Weise können Sie sicherstellen, dass Low-Level-Komponenten nicht versehentlich von einer Komponente auf höherer Ebene abhängig sind.

Answer 5

Im Allgemeinen sind Komponententests ein Werkzeug zum Schutz vor Regression und Regression am wahrscheinlichsten in Klassen mit den meisten Abhängigkeiten auftreten. Sie sollten nicht wählen müssen, Sie sollten alle Klassen testen, aber wenn Sie müssen, testen Sie die Klassen, die im Allgemeinen die meisten Abhängigkeiten haben.