Bonjour, c'est dayossi des ingénieurs iOS.
Je veux offrir un service qui rend ma famille heureuse Nous avons publié une application de journal familial appelée HaloHalo.
Cette fois, à propos du test unitaire Je voudrais régler les prérequis que je n'ai pas bien compris.
Même lorsque l'application est en cours d'exécution Une technique pour vérifier en permanence si votre code fonctionne.
Le débogage avec print () vous permet de vérifier les résultats de traitement uniques et les valeurs des variables, S'il existe un processus similaire dans d'autres situations, Vous devez réécrire print ().
De plus, si le même processus apparaît plusieurs fois, Il est préférable de le gérer dans un format unifié afin qu'il puisse être utilisé à plusieurs reprises. C'est plus lisible et ce que vous testez est clair.
Les tests unitaires sont effectués sous un format unifié Le résultat d'un traitement répété peut être obtenu automatiquement et à plusieurs reprises. Il semble que ce soit un outil qui peut être fabriqué.
(Livre de référence: livre complet de test iOS (2019) du chapitre 1)
C'est le sujet principal.
Je comprends les avantages des tests unitaires, Au contraire, "Si vous ne pouvez pas écrire dans une conception qui peut appeler le processus à plusieurs reprises, vous ne pouvez pas tester." Il semble que cela puisse être envisagé.
Je n'ai pas vraiment compris ce point, alors Ci-dessous, nous les organiserons dans l'ordre.
Par exemple, traitement dans une classe spécifique Si vous instanciez la classe à chaque fois et appelez le processus.
Ceci est un cas dépendant de la classe Le processus et la classe ne sont pas séparés.
Comme indiqué ci-dessous, sortAscendData () décrit dans le contrôleur de vue Si vous souhaitez l'utiliser avec OtherViewCotroller
À ce rythme, vous pouvez instancier et appeler le contrôleur de vue. Vous devrez écrire le même code dans OtherViewCotroller.
Si de nombreux efforts similaires se produisent, la quantité de code à écrire augmentera inutilement, Lors de la vérification du comportement de l'ensemble de l'application, il devient difficile de comprendre où le bogue s'est produit.
//Contrôleur de vue référencé
import UIKit
class ViewController: UIViewController {
var userDataCollection:[String] = []
override func viewDidLoad() {
super.viewDidLoad()
//Voir le dessin
setupView()
}
func setupView(){
//Dessiner une vue
self.view.addSubview(<#T##view: UIView##UIView#>)
}
func getUserData(){
//Processus d'acquisition des données utilisateur
}
func reloadView(){
//Afficher le rafraîchissement
}
func didTacAction(){
//Détection du mouvement du robinet
}
func sortAscendData(_ userDataCollection:Array<String>){
//Processus de tri des données
}
}
//ViewController que vous voulez voir
class OtherViewController: UIViewController {
//Les données d'affichage sont stockées et je souhaite trier...
var otherUserData: [String] = []
let vc = ViewController()
vc.sortAscendData(self.otherUserData)
// MARK:-Tout ce dont tu as vraiment besoin c'est ça...
func sortAscendData(_ userDataCollection:Array<String>){
//Processus de tri des données
}
}
Le processus commun utilisé dans diverses situations est Si vous le résumez avec le protocole,
Sans dépendre d'une classe spécifique En outre, il devient clair qu'il existe un processus commun dans le protocole. Il sera plus facile de vérifier le comportement de l'ensemble de l'application.
Par conséquent, si les responsabilités ne peuvent être partagées pour chaque dossier Puisqu'il devient difficile d'extraire le processus que vous souhaitez tester,
Tout d'abord, une conception qui peut clarifier "où et quel type de responsabilité avez-vous?" Je pense qu'il est important d'y réfléchir.
Être conscient du design signifie On peut dire qu'il est clair quel rôle est géré par quel fichier.
Je pense que le nombre de fichiers à gérer augmentera inévitablement, Il facilite à la fois la vérification automatique par l'unité de test et la vérification visuelle. Je pense que ce sera efficace même dans les situations où vous êtes conscient de la vitesse de développement.
J'écrirai de plus en plus de tests unitaires!
(Je vous serais reconnaissant si vous pouviez me donner un tsukkomi chaleureux comme "N'est-il pas normal de penser de cette façon ici?")
Kazuaki Matsuo, Yusuke Hosonuma, Kenji Tanaka et al. IOS Test Complete Book (2019) Introduction à Swift Unit Test Politique de développement d'applications IOS pour la conception simultanée lors de l'écriture de code J'ai essayé de créer une application iOS avec MVC maintenant (Swift) / Kai
Recommended Posts