Hallo, das ist Dayossi von iOS-Ingenieuren.
Ich möchte einen Service anbieten, der meine Familie glücklich macht Wir haben eine Familientagebuch-App namens [HaloHalo] veröffentlicht (https://hallo-hallo.sakura.ne.jp/home/).
Diesmal über den Unit-Test Ich möchte die Voraussetzungen klären, die ich nicht gut verstanden habe.
Auch wenn die App läuft Eine Technik zur kontinuierlichen Überprüfung, ob der Code funktioniert.
Durch das Debuggen mit print () können Sie einzelne Verarbeitungsergebnisse und Variablenwerte überprüfen. Wenn es in anderen Situationen einen ähnlichen Prozess gibt, Sie müssen print () erneut schreiben.
Auch wenn der gleiche Prozess viele Male auftritt, Es ist besser, es in einem einheitlichen Format zu verwalten, damit es wiederholt verwendet werden kann. Es ist besser lesbar und es ist klar, was Sie testen.
Unit-Tests werden in einem einheitlichen Format durchgeführt Das Ergebnis einer wiederholten Verarbeitung kann automatisch und wiederholt erhalten werden. Es scheint, dass es ein Werkzeug ist, das gemacht werden kann.
(Nachschlagewerk: Vollständiges iOS-Testbuch (2019) aus Kapitel 1)
Dies ist das Hauptthema.
Ich verstehe die Vorteile von Unit-Tests, Im Gegenteil: "Wenn Sie nicht in ein Design schreiben können, das den Prozess wiederholt aufrufen kann, können Sie nicht testen." Es scheint, dass es in Betracht gezogen werden kann.
Ich habe diesen Punkt also nicht wirklich verstanden Im Folgenden werden wir sie in der richtigen Reihenfolge organisieren.
Zum Beispiel die Verarbeitung in einer bestimmten Klasse Wenn Sie die Klasse jedes Mal instanziieren und den Prozess aufrufen.
Dies ist ein klassenabhängiger Fall Der Prozess und die Klasse sind nicht getrennt.
Wie unten gezeigt, sortAscendData () im View Controller beschrieben Wenn Sie es mit OtherViewCotroller verwenden möchten
Mit dieser Geschwindigkeit können Sie den View Controller instanziieren und aufrufen. Sie müssen denselben Code in OtherViewCotroller schreiben.
Wenn viele ähnliche Anstrengungen unternommen werden, erhöht sich die Menge des zu schreibenden Codes verschwenderisch. Wenn Sie das Verhalten der gesamten App überprüfen, wird es schwierig zu verstehen, wo der Fehler aufgetreten ist.
//Referenzierter View Controller
import UIKit
class ViewController: UIViewController {
var userDataCollection:[String] = []
override func viewDidLoad() {
super.viewDidLoad()
//Zeichnung anzeigen
setupView()
}
func setupView(){
//Ansicht zeichnen
self.view.addSubview(<#T##view: UIView##UIView#>)
}
func getUserData(){
//Prozess der Benutzerdatenerfassung
}
func reloadView(){
//Neu zeichnen anzeigen
}
func didTacAction(){
//Erkennung von Hahnbewegungen
}
func sortAscendData(_ userDataCollection:Array<String>){
//Datensortierungsprozess
}
}
//ViewController, den Sie sehen möchten
class OtherViewController: UIViewController {
//Anzeigedaten werden gespeichert und ich möchte sortieren...
var otherUserData: [String] = []
let vc = ViewController()
vc.sortAscendData(self.otherUserData)
// MARK:-Alles was Sie wirklich brauchen ist dies...
func sortAscendData(_ userDataCollection:Array<String>){
//Datensortierungsprozess
}
}
Der in verschiedenen Situationen übliche Prozess ist Wenn Sie es mit Protokoll abstrahieren,
Ohne von einer bestimmten Klasse abhängig zu sein Es wird auch klar, dass es im Protokoll einen gemeinsamen Prozess gibt. Es wird einfacher sein, das Verhalten der gesamten App zu überprüfen.
Daher, wenn die Verantwortlichkeiten nicht für jede Datei geteilt werden können Da es schwierig wird, den zu testenden Prozess zu extrahieren,
Zunächst ein Design, das klarstellen kann, "wo und welche Art von Verantwortung haben Sie?" Ich denke, es ist wichtig, darüber nachzudenken.
Design bewusst zu sein bedeutet Man kann sagen, dass klar ist, welche Rolle von welcher Datei verwaltet wird.
Ich denke, dass die Anzahl der zu verwaltenden Dateien zwangsläufig zunehmen wird. Dies erleichtert die automatische Überprüfung durch die Testeinheit und die visuelle Überprüfung. Ich denke, es wird auch in Situationen effektiv sein, in denen Sie sich der Entwicklungsgeschwindigkeit bewusst sind.
Ich werde immer mehr Unit-Tests schreiben!
(Ich würde es begrüßen, wenn Sie mir ein warmes Tsukkomi geben könnten, wie "Ist es nicht in Ordnung, hier so zu denken?")
Kazuaki Matsuo, Yusuke Hosonuma, Kenji Tanaka et al., IOS Test Complete Book (2019) Einführung in den Swift Unit Test IOS-Anwendungsentwicklungsrichtlinie zum gleichzeitigen Entwerfen beim Schreiben von Code Ich habe versucht, jetzt eine iOS-Anwendung mit MVC (Swift) / Kai zu erstellen
Recommended Posts