Es gibt immer noch nicht viele Informationen zu den realen Erfahrungen von XCode7 und Swift 2.0 aus der Sicht eines Unit Testing und Code Coverage.
Obwohl es viele Tutorials und grundlegende Anleitungen gibt, frage ich mich, wie die Erfahrungswerte und die typischen Statistiken zu den verschiedenen iOS-Teams aussehen, die tatsächlich versucht haben, eine angemessene Abdeckung für ihre veröffentlichten iOS / Swift-Apps zu erreichen. Ich frage mich speziell:
1) während der Codeabdeckungsprozentsatz nicht die Gesamtqualität der Codebasis darstellt, wird dies als eine wesentliche Messgröße in Ihrem Team verwendet? Wenn nicht, was ist der andere messbare Weg, um die Qualität Ihrer Code-Basis zu bewerten?
2) Für eine etwas robustere App, wie hoch ist Ihr aktueller Abdeckungsgrad? (Nur fyi, wir haben es schwer, über 50% für unsere aktuelle Codebasis zu bekommen)
3) Wie testen Sie Dinge wie:
Ich verstehe, dass einige der obigen Punkte eher ein Thema für tatsächliche UI-Tests sind, aber ich frage mich:
Ich freue mich auf eine fruchtbare Diskussion.
Sie stellen eine sehr große und gute Frage. Obwohl Ihre Frage beinhaltet:
Ich frage mich, was die Erfahrung und die typischen Statistiken über die Abdeckung in verschiedenen iOS-Teams sind ...
Ich denke, das Problem ist Sprache / OS Agnostiker. Sicher, einige Sprachen und Plattformen sind besser testbar als andere. So sind manche im Unit-Test teurer (im Gegensatz zu anderen Formen automatisierter / codierter Tests). Ich denke, Sie suchen nach einer Kosten-Nutzen-Gleichung, um die Produktivität zu maximieren. Ah der Spaß an Software-Entwicklungsprozessen.
Um zum Ende zu springen, um Ihnen die schnelle Antwort zu geben:
Sie sollten den all Code testen, den Sie verwenden möchten, und er ist für Komponententests geeignet.
Nun also, warum all und warum die Betonung auf Komponententests liegt ...
Was ist ein Komponententest?
Die Sprache in der Entwicklergemeinschaft ist korrupt, also bitte ertragen Sie mit mir. Unit Testing ist nur eine Art von automatisierten Tests. Andere sind automatisierte Abnahmetests, Anwendungstests, Integrationstests und Komponententests. Sie alle testen verschiedene Dinge. Sie haben unterschiedliche Zwecke.
Wenn ich jedoch Unit Testing höre, fallen mir zwei Dinge ein:
Bei TDD geht es darum, vor dem Schreiben von Code Tests zu schreiben. Es ist eine sehr niedrige Programmierpraxis / Prozess (XP - eXtreme Programming), während Sie einen Test schreiben, um eine Anweisung zu schreiben und dann einen anderen Test. Sehr viel eine Kodierungspraxis, aber keine Anwendung / Anforderungspraxis, wie es ist, Code zu schreiben, der tut, was Sie beabsichtigten, nicht, was die Produktanforderungen sind (oh Gott, ich fühle, dass die Punkte verloren sind).
Schreiben Code und dann Unit-Test ist es ... meiner Erfahrung nach ... Spaß, kurzfristige Teambildung, aber nicht produktiv. Sicher sind einige Mängel gefunden, aber nicht viele. TDD führt zu besserem "gesundem" Code.
Mein Punkt hier ist, dass Unit Testing ist:
Warum alle?
Wenn Ihr Team Null-Fehler-Software liefert (ZDFD ist real und erreichbar ... aber das ist eine flache Erddiskussion), die ganze Zeit ohne Komponententests, dann ist das Unsinn und Sie würden hier keine Fragen stellen.
Der einzige triftige Grund dafür, dass ein Team Komponententests als Teil seines Codierprozesses einbaut, ist die Verbesserung der Produktivität. Wenn sich alle Teammitglieder zur Teamproduktivität verpflichten, besteht das einzige Problem darin, zu ermitteln, welcher Code vom Komponententest profitiert. Dies ist der Kontext von all .
Der einfachste Weg, dies zu illustrieren, ist, Typen aufzulisten, die ich nicht als Komponententest verwende:
Die praktische Antwort
Meine Teams haben eine 100% -Testabdeckung für alle neuen Codes erwartet, die getestet werden sollten. Dies wird erreicht, indem Code zugewiesen wird, der die Kriterien für das Komponententest nicht erfüllt. Der gesamte Code muss die Codeüberprüfung durchlaufen, und die Attribute müssen für die oben aufgeführten Warum-Optionen spezifisch sein. - Einfach.
Eine lange Antwort und vielleicht nicht leicht zu verdauen, noch was die Leute hören wollen. Aber aus langer Erfahrung weiß ich, dass es die beste Antwort ist, die zu bester Rentabilität führen kann.
Kommentar posten
Meine Antwort zielt auf das Testen der Aspekte der Frage. Was die defensive Programmierung und andere Praktiken anbetrifft, ist TDD ein Prozess, der dies mindert, indem es erschwert wird, das Falsche zu tun. Statische Codeanalyse-Tools für das Build-System können Ihnen jedoch dabei helfen, diese zu erfassen, bevor sie zur Peer-Überprüfung kommen (sie können einen Build bei neuen Problemen nicht bestehen). Sehen Sie sich andere an wie SonarQube, Resharper, CppDepend, NDepend (ja sprachabhängig).
Tags und Links unit-testing ios xcode code-coverage swift