Ich bin gespannt, was ein vernünftiger / typischer Wert für das Verhältnis von Testcode zu Produktionscode ist, wenn Leute TDD machen. Wenn ich eine Komponente betrachte, habe ich 530 Zeilen Testcode für 130 Zeilen Produktionscode. Eine andere Komponente hat 1000 Zeilen Testcode für 360 Zeilen Produktionscode. So benötigen die Komponententests ungefähr 3x bis 5x soviel Code. Dies ist für Javascript-Code. Ich habe nicht viel getestet C # -Code praktisch, aber ich denke, für ein anderes Projekt sah ich auf 2x bis 3x so viel Testcode dann Produktionscode.
Es scheint mir, dass der niedrigere Wert, sofern die Tests ausreichend sind, höhere Qualitätstests widerspiegeln würde. Reine Spekulation, ich frage mich nur, welche Verhältnisse andere Leute sehen.
Ich weiß, dass Codezeilen eine lose Metrik sind, aber da ich sowohl für den Test als auch für die Produktion im selben Stil code (dasselbe Format, dieselbe Menge an Kommentaren usw.), sind die Werte vergleichbar.
Dies hängt wirklich davon ab, wie gut die Dinge berücksichtigt werden, aber nach meiner Erfahrung (ja, ich habe das an einigen Projekten gemessen), habe ich Verhältnisse von 2: 1 bis 5: 1 gesehen (dies ist für getesteten Code von Kurs). Sehen Sie sich auch die ProductionCodeVsUnitTestsRatio und UnitTestToCodeRatio Seiten im C2-Wiki.
Wow, diese Zahlen sind ziemlich groß! Ich bin ungefähr 1: 1, manchmal für Klassen, die eine höhere zyklomatische Komplexität haben, kann es näher 2: 1 für Einheitstests LOC gehen, aber dann löst das Alarmglocken aus, die die Klasse Refactoring benötigt.
Sie erwähnen, dass Sie den gleichen Stil für Ihre Komponententests verwenden. Das ist gut, wenn Sie Ihre Tests als Produktionscode behandeln, aber brauchen Sie wirklich viele Kommentare für den Testcode? Benennen Sie Ihre Testmethoden so, dass sie beschreiben, was der Test behauptet? zum Beispiel mit dem 'GivenXWhenYThenZ' Funktionsnamen, dann sollte es ziemlich klar sein, was der Test ohne einen großen Kommentarabschnitt macht.
Refaktorieren Sie Ihre Tests? Verschieben von irgendwelchen Duplikaten von Setup usw. in separate Methoden?
Halten Sie Ihre Komponententests einfach, so dass sie nur eine Sache pro Test bestätigen?
und testen Sie Dinge wie Getter / Setter übermäßig?
Verschiedene Sprachen und Test-Frameworks werden sehr unterschiedlich sein. Zum Beispiel, BDD Frameworks viel "DRYer" als TestUnit-Stil-Code. Außerdem hatte ich bei einigen Projekten sehr große Datenmengen, die nur durch ein paar Java-Zeilen gespeist wurden - die tausende von Zeilen des Codes getestet haben -, so dass mein Verhältnis ganz verrückt wäre.
Ich habe mir nur meine drei jüngsten Projekte (mittelgroße Schienen) angeschaut und die Code-zu-Test-Verhältnisse waren 1: 2,3, 1: 1,6 und 1: 1,9 ... also klingen die Zahlen so, als wären sie ähnlich. (Ich habe gerade rake stats ausgeführt - ich habe sie vorher nie wirklich angeschaut.)
Wie auch immer, Warnzeichen, dass Sie zu viele Tests haben:
Ich persönlich verwende ein Verhältnis von Assertion zu Loc. Einige Dinge erfordern möglicherweise mehr Modell und Setup-Code zum Testen als andere. Ich fühle, dass die X-Zeilen von Testcode zu Y-Zeilen von Produktcode möglicherweise nicht sehr nützlich sind. Ein Code-Coverage-Tool ist wahrscheinlich der beste Weg, um es zu betrachten. Ich habe in meinen letzten zwei Projekten gefunden, dass mein Code 1 Assert pro 10 Zeilen Produktionscode hat. Bekommt jemand andere ähnliche Werte?
Tags und Links unit-testing tdd